CasaOS seems to disconnect Proxmox node

jlgarnier · May 18, 2026, 7:56am

Dear Community,

I’ve installed a CasaOS VM on a Proxmox (v9.x) lab server. This VM replaces a previous OpenMediaVault VM that accidentally crashed and couldn’t be recovered (physical disk issue due to a storm). The OMV VM has run for months (approx. 18 months) without any issue.

Now the CasaOS VM is running less that a week and the server disconnects from the Proxmox cluster (this is how I detect the disconnection: SRV1 notifies me that SRV2 has been lost).

Metrics give: CPU usage = 5%, RAM < 25%, temp is normal…

I don’t understand why it has this weird behavior since I installed CasaOS and am keen to investigate: system logs don’t return any relevant information (some warnings “pcieport 0000:00:1b.0: PCIe Bus Error: severity=Correctable, type=Physical Layer, (Receiver ID)”), which logfile should I look into?

Thanks in advance for any help!

gelbuilding · May 18, 2026, 9:53am

I would not jump straight to blaming CasaOS itself yet, especially if the Proxmox node is actually dropping from the cluster rather than just the VM becoming unreachable.

The important clue here is this:

pcieport ... PCIe Bus Error: severity=Correctable

“Correctable” PCIe errors usually mean the hardware/link recovered, but repeated PCIe bus errors can still point to underlying instability:

failing NVMe/SATA device
bad PCIe lane/link training
power issue after the storm
flaky RAM
motherboard/slot instability
NIC issues
ASPM/power-management quirks

Since the previous OMV VM died from a physical disk issue after the storm, I would honestly suspect lingering hardware instability before blaming CasaOS.

A few things I would check first:

Confirm whether the entire Proxmox node is briefly freezing/disconnecting, or only the CasaOS VM.
Check the Proxmox host logs directly, not only inside the VM:

journalctl -b -1 -p err

dmesg -T | grep -iE "pcie|aer|nvme|reset|link down|I/O error"

pveproxy status

Verify storage health on the Proxmox host:

smartctl -a /dev/nvme0n1

or for SATA:

smartctl -a /dev/sdX

Watch for cluster/network drops:

journalctl -u corosync

If you are passing through disks/controllers to the VM, temporarily remove passthrough and test with a normal virtual disk only.

Also worth noting:

CasaOS itself is fairly lightweight.
A normal CasaOS VM should not destabilize a healthy Proxmox node.
Cluster disconnects are often networking, storage stalls, or kernel/hardware related underneath.

The PCIe errors are the part I would focus on first.

jlgarnier · May 18, 2026, 11:46am

Thanks a lot for this detailed (and quick) answer!

I’m leaving for a business trip this afternoon, so I won’t have the time to follow your advices and investigate deeper into the system, but will get back in touch next week with the outcome!

Thanks again!

jlgarnier · May 23, 2026, 2:53pm

Hi @gelbuilding !

You were absolutely right: the issue came from a weak Proxmox configuration! Actually, I was playing with a 2-server cluster and Proxmox had trouble finding the proper ‘quorum’ when server1 quickly disconnected (a few milliseconds was enough) during backup operation. It then considered the second node was lost and eventually disconnected from the network (no GUI, no SSH).

I then removed both nodes from the cluster and deleted the cluster itself, so now both machines are fully independant.

However, this raised a new issue: the VM on server1 that hosts the CasaOS environment has properly rebooted and I can reach CasaOS with the existing credentials. Unfortunately, all installed applications have gone: the login page just displays ‘App Store’ and ‘Files’ widgets, although Portainer, Nextcloud and other applications were installed and running.

CasaOS was also installed on the second server and applications installed on this VM are still accessible, so the issue only displays on server1…

Any clue on how to fix this? Is there any ‘registry’ to refresh?

Thanks in advance for your advices!

gelbuilding · May 23, 2026, 3:05pm

Good catch on the quorum issue. A two-node Proxmox cluster without a quorum device can definitely behave unexpectedly during brief network interruptions, so it makes sense that removing the cluster resolved the disconnects.

Regarding CasaOS, if the applications are still running but only App Store and Files are shown in the dashboard, I would first check whether this is a UI/database issue rather than an actual loss of the applications.

A few questions:

Are the containers still visible in Portainer or via Docker?
Can you still access any of the applications directly by their IP:port?
Does the Applications page in CasaOS show the apps as installed, or is it completely empty?

If the containers are still running and accessible, then the CasaOS dashboard may have lost its application registry/state information while the actual Docker containers and AppData remain intact.

I would avoid reinstalling anything at this stage. The first step is to confirm whether the containers and AppData are still present. If they are, there’s a good chance the applications can be re-associated with the CasaOS interface rather than rebuilt from scratch.

Let us know whether the containers are still running and whether the apps are reachable directly, and we can narrow it down further.

jlgarnier · May 23, 2026, 4:20pm

Thanks for your quick answer!

Actually

Portaner is not accessible anymore (installed via CasaOS).
docker ps returns nothing (empty list).
CasaOS’ application page only displays ‘App Store’ and ‘Files’.

Direct access to the applications (using their IP:poprt addresses) also fails.

/DATA/AppData still contains applications’ private data folders (ex. big-bear-portainer, big-bear-nextcloud…).

gelbuilding · May 24, 2026, 4:34am

That actually sounds encouraging.

If docker ps returns an empty list and none of the applications are reachable, then the containers themselves are no longer running. The fact that your /DATA/AppData folders are still present means the application data appears to have survived, which is the most important part.

My first suspicion would be that Docker was reset, stopped, or its metadata/database was lost during the cluster changes or subsequent reboot, rather than the application data being deleted.

Could you check:

docker ps -a

and

systemctl status docker

If docker ps -a also returns nothing, then CasaOS has likely lost track of the installed applications even though the AppData folders remain on disk.

Also, can you confirm whether the contents of /DATA/AppData/big-bear-portainer and /DATA/AppData/big-bear-nextcloud still look intact (files and subfolders present)?

The good news is that if the AppData is still there, recovery is often much easier than rebuilding everything from scratch.

jlgarnier · May 24, 2026, 9:38am

The command docker ps -a returns nothing, while systemctl status docker indicates that the service is up and running. Indeed, it looks like Docker’s config files / database has been unexpectingly corrupted during the cluster split…

Browsing through Nextcloud folders shows regular Nextcloud files in expected places: what do you suggest to bring apps back to life?

gelbuilding · May 24, 2026, 9:46am

The fact that your AppData folders are intact is very good news. In most cases, the valuable data lives there, while Docker containers themselves can be recreated.

Before attempting any reinstall or recovery, I would check whether Docker is using the expected data directory and whether the original container metadata still exists somewhere on disk.

Can you check:

docker info | grep "Docker Root Dir"

and then verify whether that directory contains containers and image data?

It would also be useful to see:

docker info

If Docker is pointing to a new or empty data directory, the original containers may still exist elsewhere on the system.

I would avoid reinstalling Nextcloud, Portainer, or any other applications until we understand what happened to Docker’s metadata. Since your /DATA/AppData/big-bear-* folders are still present and appear intact, there is a good chance the application data can be reused once the container definitions are restored or recreated.

jlgarnier · May 24, 2026, 10:16am

Thanks for the pointers!

docker info | grep “Docker Root Dir” returns: Docker Root Dir: /var/lib/docker. I can’t check whether the folder content is OK but it is at least populated:



$ sudo ls /var/lib/docker/containers -l
total 36
drwx–x— 4 root root 4096 May 23 14:43 02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b
drwx–x— 4 root root 4096 May 23 14:43 29c75f6c4d0433cda8b7ae26ff6924d51ca23fb5be0c1807deadd802faaafa08
drwx–x— 4 root root 4096 May 23 14:43 513b409652ad299fed1c53f7c0c1cdb3ecac232f8e8985c9c5d1750641d1e673
drwx–x— 4 root root 4096 May 23 14:43 5bd2c05370c98997f68f0fa44913064c28062295393b571cdd5fb12a6ddbdc35
drwx–x— 4 root root 4096 May 23 14:43 7c0bef2e02cb118c24063d8c06be1c8cf40d66463701bb6259eea17b90ed2b64
drwx–x— 4 root root 4096 May 23 14:43 a9bd8d88bf8bd5be98de4ed177d5dd25121332f8881cf1609b50644b638c53b8
drwx–x— 4 root root 4096 May 23 14:43 c19e16f0ea5c0e56216e4cab6b8177a972394e58a218d13f93341d211522ab4a
drwx–x— 4 root root 4096 May 23 14:43 e75325ca76c92d3c232bfb0f74734d830ec942ba0065c111afd0ff4734554096
drwx–x— 4 root root 4096 May 23 14:43 f1598e7c3de768878c2209081df4a1bc33ab97d8a50ebbd21c57d003873748e8

Here’s the docker info outcome:

Client: Docker Engine - Community
Version:    29.4.1
Context:    default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version:  v0.33.0
Path:     /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version:  v5.1.3
Path:     /usr/libexec/docker/cli-plugins/docker-compose
model: Docker Model Runner (Docker Inc.)
Version:  v1.1.37
Path:     /usr/libexec/docker/cli-plugins/docker-model

Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 9
Server Version: 29.4.1
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: 77c84241c7cbdd9b4eca2591793e3d4f4317c590
runc version: v1.3.5-0-g488fc13e
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 7.0.0-14-generic
Operating System: Ubuntu 26.04 LTS
OSType: linux
Architecture: x86_64
CPUs: 4
Total Memory: 7.25GiB
Name: lab-server1
ID: da0ba6b8-a46a-45e5-aee9-72ab629c40d1
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: false
Firewall Backend: iptables

I noticed that there’s 9 images listed although 0 container is found… Hope this helps!

gelbuilding · May 24, 2026, 10:30am

This is actually very interesting.

Docker is reporting 0 containers, yet /var/lib/docker/containers contains multiple container directories and Docker still knows about 9 images. That suggests the Docker installation itself is working, but its container metadata may no longer be consistent with what is stored on disk.

The fact that the container directories still exist is encouraging because it means Docker was definitely managing containers on this system recently. The timestamps also appear to line up with when the issue occurred.

Before attempting to reinstall any applications, I’d be curious to see whether Docker can still discover metadata for those container IDs. Could you check one of them, for example:

sudo ls -l /var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b

and see whether a config.v2.json file exists inside?

At this point I would avoid reinstalling Nextcloud, Portainer, or other apps. Your AppData folders are still present, the Docker image store is still present, and the container directories are still present. We first need to determine whether this is a metadata/indexing problem or whether Docker genuinely lost the container definitions.

Also, did the cluster removal involve any restoration, snapshot rollback, filesystem repair, or manual edits under /var/lib/docker? That detail may help explain how Docker ended up with images and container directories on disk but reports zero containers.

jlgarnier · May 24, 2026, 10:38am

Nailed it! The command returned

$ sudo ls -l /var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b
[sudo: authenticate] Password:
total 5084
-rw-r----- 1 root root 5161468 May 23 13:00 02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b-json.log
drwx------ 2 root root    4096 Apr 28 14:56 checkpoints
-rw------- 1 root root    6581 May 23 13:00 config.v2.json
-rw------- 1 root root    1740 May 23 13:00 hostconfig.json
-rw-r–r-- 1 root root      13 May 12 06:48 hostname
-rw-r–r-- 1 root root     148 May 23 13:00 hosts
drwx–x— 2 root root    4096 Apr 28 14:56 mounts
-rw-r–r-- 1 root root     267 May 12 06:48 resolv.conf
-rw-r–r-- 1 root root      71 May 12 06:48 resolv.conf.hash

so there’s indeed a config.v2.json file!

Regarding the cluster deletion, I don’t remember of any message asking for restoration, repair or any similar actions required for the Docker engine…

gelbuilding · May 24, 2026, 10:50am

Now that’s a very interesting result.

The presence of config.v2.json and hostconfig.json tells us these are not just leftover folders. Docker container definitions still exist on disk, complete with configuration and logs.

What’s puzzling is that Docker reports:

9 images
0 containers

while /var/lib/docker/containers clearly contains multiple valid container directories.

That doesn’t look like a normal CasaOS issue. It looks more like Docker’s internal metadata database has become out of sync with the container files on disk.

Before touching anything, I’d be interested in identifying what one of these containers actually was. Could you run:

sudo grep '"Name"' /var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/config.v2.json

and also:

sudo grep '"Image"' /var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/config.v2.json

That should tell us whether we’re looking at a former Nextcloud, Portainer, CasaOS service, or something else.

At this stage I still would not reinstall applications. The evidence so far suggests:

AppData is still present
Docker images are still present
Container configuration files are still present
Only Docker’s active container inventory appears to be missing

If we can identify the containers from their config.v2.json files, we may get a much clearer picture of what was lost and whether recovery is possible without rebuilding everything from scratch.

jlgarnier · May 24, 2026, 12:31pm

Here’s the response to the first command:

$ sudo ls -l /var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b
total 5084
-rw-r----- 1 root root 5161468 May 23 13:00 02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b-json.log
drwx------ 2 root root    4096 Apr 28 14:56 checkpoints
-rw------- 1 root root    6581 May 23 13:00 config.v2.json
-rw------- 1 root root    1740 May 23 13:00 hostconfig.json
-rw-r–r-- 1 root root      13 May 12 06:48 hostname
-rw-r–r-- 1 root root     148 May 23 13:00 hosts
drwx–x— 2 root root    4096 Apr 28 14:56 mounts
-rw-r–r-- 1 root root     267 May 12 06:48 resolv.conf
-rw-r–r-- 1 root root      71 May 12 06:48 resolv.conf.hash
jlgarnier@lab-server1:~$ sudo grep ‘“Name”’ /var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/config.v2.json
[sudo: authenticate] Password:
{“StreamConfig”:{},“State”:{“Running”:false,“Paused”:false,“Restarting”:false,“OOMKilled”:false,“Dead”:false,“Pid”:0,“ExitCode”:0,“Error”:“”,“StartedAt”:“2026-05-12T06:48:56.085606682Z”,“FinishedAt”:“2026-05-23T13:00:55.638398725Z”,“Health”:null},“ID”:“02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b”,“Created”:“2026-04-28T14:56:07.890905714Z”,“Managed”:false,“Path”:“/init”,“Args”:[“/scripts/cmd.sh”,“/opt/photoprism/bin/photoprism”,“start”],“Config”:{“Hostname”:“02017d85afcc”,“Domainname”:“”,“User”:“”,“AttachStdin”:false,“AttachStdout”:true,“AttachStderr”:true,“ExposedPorts”:{“2342/tcp”:{},“2442/tcp”:{},“2443/tcp”:{}},“Tty”:false,“OpenStdin”:false,“StdinOnce”:false,“Env”:[“PHOTOPRISM_UPLOAD_NSFW=true”,“TZ=Etc/UTC”,“OPENAI_API_KEY=sk-xxxxxx”,“PHOTOPRISM_ADMIN_PASSWORD=casaos”,“PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/scripts:/opt/photoprism/bin”,“PHOTOPRISM_ARCH=amd64”,“DOCKER_TAG=250228”,“DOCKER_ENV=prod”,“PS1=\u@250221-oracular-slim:\w$ “,“LD_LIBRARY_PATH=/usr/local/lib:/usr/lib”,“TMPDIR=/tmp”,“DEBIAN_FRONTEND=noninteractive”,“TF_CPP_MIN_LOG_LEVEL=2”,“MALLOC_ARENA_MAX=4”,“PROG=photoprism”,“S6_KEEP_ENV=1”,“S6_LOGGING=0”,“PHOTOPRISM_ASSETS_PATH=/opt/photoprism/assets”,“PHOTOPRISM_IMPORT_PATH=/photoprism/import”,“PHOTOPRISM_ORIGINALS_PATH=/photoprism/originals”,“PHOTOPRISM_STORAGE_PATH=/photoprism/storage”,“PHOTOPRISM_BACKUP_PATH=/photoprism/storage/backups”,“PHOTOPRISM_LOG_FILENAME=/photoprism/storage/photoprism.log”,“PHOTOPRISM_PID_FILENAME=/photoprism/storage/photoprism.pid”,“PHOTOPRISM_DEBUG=false”,“PHOTOPRISM_PUBLIC=false”,“PHOTOPRISM_READONLY=false”,“PHOTOPRISM_DETECT_NSFW=false”,“PHOTOPRISM_EXPERIMENTAL=false”,“PHOTOPRISM_SITE_CAPTION=AI-Powered Photos App”,“PHOTOPRISM_SITE_DESCRIPTION=AI-Powered Photos App for the Decentralized Web”,“PHOTOPRISM_SITE_AUTHOR=”,“PHOTOPRISM_HTTP_HOST=0.0.0.0”,“PHOTOPRISM_HTTP_PORT=2342”,“PHOTOPRISM_DISABLE_TLS=false”,“PHOTOPRISM_DEFAULT_TLS=false”,“PHOTOPRISM_DISABLE_STS=true”,“PHOTOPRISM_DATABASE_DRIVER=sqlite”,“PHOTOPRISM_DATABASE_SERVER=”,“PHOTOPRISM_DATABASE_NAME=photoprism”,“PHOTOPRISM_DATABASE_USER=photoprism”,“PHOTOPRISM_DATABASE_PASSWORD=”,“PHOTOPRISM_DISABLE_CHOWN=false”,“PHOTOPRISM_DISABLE_WEBDAV=false”,“PHOTOPRISM_DISABLE_SETTINGS=false”,“PHOTOPRISM_DISABLE_BACKUPS=false”,“PHOTOPRISM_DISABLE_EXIFTOOL=false”,“PHOTOPRISM_DISABLE_PLACES=false”,“PHOTOPRISM_DISABLE_TENSORFLOW=false”,“PHOTOPRISM_DISABLE_FACES=false”,“PHOTOPRISM_DISABLE_CLASSIFICATION=false”,“PHOTOPRISM_RAW_PRESETS=false”,“PHOTOPRISM_THUMB_SIZE=1920”,“PHOTOPRISM_THUMB_SIZE_UNCACHED=7680”,“PHOTOPRISM_THUMB_UNCACHED=true”,“PHOTOPRISM_JPEG_SIZE=7680”,“PHOTOPRISM_PNG_SIZE=7680”,“PHOTOPRISM_AUTO_INDEX=300”,“PHOTOPRISM_AUTO_IMPORT=-1”,“PHOTOPRISM_INIT=https”],“Cmd”:[”/scripts/cmd.sh”,“/opt/photoprism/bin/photoprism”,“start”],“Image”:“photoprism/photoprism:250228”,“Volumes”:null,“WorkingDir”:“/photoprism”,“Entrypoint”:[“/init”],“Labels”:{“com.docker.compose.config-hash”:“580fa8c990c2753c4cb858001c04841336003924481c452a0a63d27196327814”,“com.docker.compose.container-number”:“1”,“com.docker.compose.depends_on”:“”,“com.docker.compose.image”:“sha256:8f1cb70617cb97c2b675ad63334be57e962f91e58967e81ae31bc58fc00ed304”,“com.docker.compose.oneoff”:“False”,“com.docker.compose.project”:“photoprism”,“com.docker.compose.project.config_files”:“/var/lib/casaos/apps/photoprism/docker-compose.yml”,“com.docker.compose.project.working_dir”:“/var/lib/casaos/apps/photoprism”,“com.docker.compose.service”:“photoprism”,“com.docker.compose.version”:“”,“icon”:“https://cdn.jsdelivr.net/gh/IceWhaleTech/CasaOS-AppStore@main/Apps/PhotoPrism/icon.png",“org.opencontainers.image.authors”:"PhotoPrism UG \u003chello@photoprism.app\u003e”,“org.opencontainers.image.description”:“Ubuntu 24.10 (Oracular Oriole)”,“org.opencontainers.image.documentation”:“https://docs.photoprism.app/getting-started/",“org.opencontainers.image.ref.name”:“photoprism”,“org.opencontainers.image.source”:“https://github.com/photoprism/photoprism”,“org.opencontainers.image.title”:"PhotoPrism® Plus (Ubuntu 24.10)”,“org.opencontainers.image.url”:“photoprism/photoprism”,“org.opencontainers.image.vendor”:“PhotoPrism UG”,“org.opencontainers.image.version”:“24.10”}},“Image”:“sha256:8f1cb70617cb97c2b675ad63334be57e962f91e58967e81ae31bc58fc00ed304”,“ImageManifest”:{“mediaType”:“application/vnd.oci.image.manifest.v1+json”,“digest”:“sha256:3e638113c3f1378501796e0e62633a1f938847c513859a469532f68374432051”,“size”:1818,“platform”:{“architecture”:“amd64”,“os”:“linux”}},“NetworkSettings”:{“SandboxID”:“”,“SandboxKey”:“”,“Networks”:{“bridge”:{“IPAMConfig”:null,“Links”:null,“Aliases”:null,“DriverOpts”:null,“GwPriority”:0,“NetworkID”:“26a8d63f7ececd3564cf1fc5a5bfcb45e6674e1ec098bffcf3c4384330363066”,“EndpointID”:“”,“Gateway”:“”,“IPAddress”:“”,“MacAddress”:“”,“IPPrefixLen”:0,“IPv6Gateway”:“”,“GlobalIPv6Address”:“”,“GlobalIPv6PrefixLen”:0,“DNSNames”:null,“IPAMOperational”:false,“DesiredMacAddress”:“”}},“Service”:null,“Ports”:null,“HasSwarmEndpoint”:false},“LogPath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b-json.log”,“Name”:“/photoprism”,“Driver”:“overlayfs”,“OS”:“linux”,“ImagePlatform”:{“architecture”:“amd64”,“os”:“linux”},“RestartCount”:0,“HasBeenStartedBefore”:true,“HasBeenManuallyStopped”:false,“MountPoints”:{“/photoprism/originals”:{“Source”:“/DATA/Gallery”,“Destination”:“/photoprism/originals”,“RW”:true,“Name”:“”,“Driver”:“”,“Type”:“bind”,“Propagation”:“rprivate”,“Spec”:{“Type”:“bind”,“Source”:“/DATA/Gallery”,“Target”:“/photoprism/originals”},“SkipMountpointCreation”:true},“/photoprism/storage”:{“Source”:“/DATA/AppData/photoprism/photoprism/storage”,“Destination”:“/photoprism/storage”,“RW”:true,“Name”:“”,“Driver”:“”,“Type”:“bind”,“Propagation”:“rprivate”,“Spec”:{“Type”:“bind”,“Source”:“/DATA/AppData/photoprism/photoprism/storage”,“Target”:“/photoprism/storage”},“SkipMountpointCreation”:true}},“SecretReferences”:null,“ConfigReferences”:null,“MountLabel”:“”,“ProcessLabel”:“”,“AppArmorProfile”:“docker-default”,“SeccompProfile”:“”,“NoNewPrivileges”:false,“WritableCgroups”:null,“HostnamePath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/hostname”,“HostsPath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/hosts”,“ShmPath”:“”,“ResolvConfPath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/resolv.conf”,“LocalLogCacheMeta”:{“HaveNotifyEnabled”:false}}

And the response to the second one:

$ sudo grep ‘“Image”’ /var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/config.v2.json
{“StreamConfig”:{},“State”:{“Running”:false,“Paused”:false,“Restarting”:false,“OOMKilled”:false,“Dead”:false,“Pid”:0,“ExitCode”:0,“Error”:“”,“StartedAt”:“2026-05-12T06:48:56.085606682Z”,“FinishedAt”:“2026-05-23T13:00:55.638398725Z”,“Health”:null},“ID”:“02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b”,“Created”:“2026-04-28T14:56:07.890905714Z”,“Managed”:false,“Path”:“/init”,“Args”:[“/scripts/cmd.sh”,“/opt/photoprism/bin/photoprism”,“start”],“Config”:{“Hostname”:“02017d85afcc”,“Domainname”:“”,“User”:“”,“AttachStdin”:false,“AttachStdout”:true,“AttachStderr”:true,“ExposedPorts”:{“2342/tcp”:{},“2442/tcp”:{},“2443/tcp”:{}},“Tty”:false,“OpenStdin”:false,“StdinOnce”:false,“Env”:[“PHOTOPRISM_UPLOAD_NSFW=true”,“TZ=Etc/UTC”,“OPENAI_API_KEY=sk-xxxxxx”,“PHOTOPRISM_ADMIN_PASSWORD=casaos”,“PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/scripts:/opt/photoprism/bin”,“PHOTOPRISM_ARCH=amd64”,“DOCKER_TAG=250228”,“DOCKER_ENV=prod”,“PS1=\u@250221-oracular-slim:\w$ “,“LD_LIBRARY_PATH=/usr/local/lib:/usr/lib”,“TMPDIR=/tmp”,“DEBIAN_FRONTEND=noninteractive”,“TF_CPP_MIN_LOG_LEVEL=2”,“MALLOC_ARENA_MAX=4”,“PROG=photoprism”,“S6_KEEP_ENV=1”,“S6_LOGGING=0”,“PHOTOPRISM_ASSETS_PATH=/opt/photoprism/assets”,“PHOTOPRISM_IMPORT_PATH=/photoprism/import”,“PHOTOPRISM_ORIGINALS_PATH=/photoprism/originals”,“PHOTOPRISM_STORAGE_PATH=/photoprism/storage”,“PHOTOPRISM_BACKUP_PATH=/photoprism/storage/backups”,“PHOTOPRISM_LOG_FILENAME=/photoprism/storage/photoprism.log”,“PHOTOPRISM_PID_FILENAME=/photoprism/storage/photoprism.pid”,“PHOTOPRISM_DEBUG=false”,“PHOTOPRISM_PUBLIC=false”,“PHOTOPRISM_READONLY=false”,“PHOTOPRISM_DETECT_NSFW=false”,“PHOTOPRISM_EXPERIMENTAL=false”,“PHOTOPRISM_SITE_CAPTION=AI-Powered Photos App”,“PHOTOPRISM_SITE_DESCRIPTION=AI-Powered Photos App for the Decentralized Web”,“PHOTOPRISM_SITE_AUTHOR=”,“PHOTOPRISM_HTTP_HOST=0.0.0.0”,“PHOTOPRISM_HTTP_PORT=2342”,“PHOTOPRISM_DISABLE_TLS=false”,“PHOTOPRISM_DEFAULT_TLS=false”,“PHOTOPRISM_DISABLE_STS=true”,“PHOTOPRISM_DATABASE_DRIVER=sqlite”,“PHOTOPRISM_DATABASE_SERVER=”,“PHOTOPRISM_DATABASE_NAME=photoprism”,“PHOTOPRISM_DATABASE_USER=photoprism”,“PHOTOPRISM_DATABASE_PASSWORD=”,“PHOTOPRISM_DISABLE_CHOWN=false”,“PHOTOPRISM_DISABLE_WEBDAV=false”,“PHOTOPRISM_DISABLE_SETTINGS=false”,“PHOTOPRISM_DISABLE_BACKUPS=false”,“PHOTOPRISM_DISABLE_EXIFTOOL=false”,“PHOTOPRISM_DISABLE_PLACES=false”,“PHOTOPRISM_DISABLE_TENSORFLOW=false”,“PHOTOPRISM_DISABLE_FACES=false”,“PHOTOPRISM_DISABLE_CLASSIFICATION=false”,“PHOTOPRISM_RAW_PRESETS=false”,“PHOTOPRISM_THUMB_SIZE=1920”,“PHOTOPRISM_THUMB_SIZE_UNCACHED=7680”,“PHOTOPRISM_THUMB_UNCACHED=true”,“PHOTOPRISM_JPEG_SIZE=7680”,“PHOTOPRISM_PNG_SIZE=7680”,“PHOTOPRISM_AUTO_INDEX=300”,“PHOTOPRISM_AUTO_IMPORT=-1”,“PHOTOPRISM_INIT=https”],“Cmd”:[”/scripts/cmd.sh”,“/opt/photoprism/bin/photoprism”,“start”],“Image”:“photoprism/photoprism:250228”,“Volumes”:null,“WorkingDir”:“/photoprism”,“Entrypoint”:[“/init”],“Labels”:{“com.docker.compose.config-hash”:“580fa8c990c2753c4cb858001c04841336003924481c452a0a63d27196327814”,“com.docker.compose.container-number”:“1”,“com.docker.compose.depends_on”:“”,“com.docker.compose.image”:“sha256:8f1cb70617cb97c2b675ad63334be57e962f91e58967e81ae31bc58fc00ed304”,“com.docker.compose.oneoff”:“False”,“com.docker.compose.project”:“photoprism”,“com.docker.compose.project.config_files”:“/var/lib/casaos/apps/photoprism/docker-compose.yml”,“com.docker.compose.project.working_dir”:“/var/lib/casaos/apps/photoprism”,“com.docker.compose.service”:“photoprism”,“com.docker.compose.version”:“”,“icon”:“https://cdn.jsdelivr.net/gh/IceWhaleTech/CasaOS-AppStore@main/Apps/PhotoPrism/icon.png",“org.opencontainers.image.authors”:"PhotoPrism UG \u003chello@photoprism.app\u003e”,“org.opencontainers.image.description”:“Ubuntu 24.10 (Oracular Oriole)”,“org.opencontainers.image.documentation”:“https://docs.photoprism.app/getting-started/",“org.opencontainers.image.ref.name”:“photoprism”,“org.opencontainers.image.source”:“https://github.com/photoprism/photoprism”,“org.opencontainers.image.title”:"PhotoPrism® Plus (Ubuntu 24.10)”,“org.opencontainers.image.url”:“photoprism/photoprism”,“org.opencontainers.image.vendor”:“PhotoPrism UG”,“org.opencontainers.image.version”:“24.10”}},“Image”:“sha256:8f1cb70617cb97c2b675ad63334be57e962f91e58967e81ae31bc58fc00ed304”,“ImageManifest”:{“mediaType”:“application/vnd.oci.image.manifest.v1+json”,“digest”:“sha256:3e638113c3f1378501796e0e62633a1f938847c513859a469532f68374432051”,“size”:1818,“platform”:{“architecture”:“amd64”,“os”:“linux”}},“NetworkSettings”:{“SandboxID”:“”,“SandboxKey”:“”,“Networks”:{“bridge”:{“IPAMConfig”:null,“Links”:null,“Aliases”:null,“DriverOpts”:null,“GwPriority”:0,“NetworkID”:“26a8d63f7ececd3564cf1fc5a5bfcb45e6674e1ec098bffcf3c4384330363066”,“EndpointID”:“”,“Gateway”:“”,“IPAddress”:“”,“MacAddress”:“”,“IPPrefixLen”:0,“IPv6Gateway”:“”,“GlobalIPv6Address”:“”,“GlobalIPv6PrefixLen”:0,“DNSNames”:null,“IPAMOperational”:false,“DesiredMacAddress”:“”}},“Service”:null,“Ports”:null,“HasSwarmEndpoint”:false},“LogPath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b-json.log”,“Name”:“/photoprism”,“Driver”:“overlayfs”,“OS”:“linux”,“ImagePlatform”:{“architecture”:“amd64”,“os”:“linux”},“RestartCount”:0,“HasBeenStartedBefore”:true,“HasBeenManuallyStopped”:false,“MountPoints”:{“/photoprism/originals”:{“Source”:“/DATA/Gallery”,“Destination”:“/photoprism/originals”,“RW”:true,“Name”:“”,“Driver”:“”,“Type”:“bind”,“Propagation”:“rprivate”,“Spec”:{“Type”:“bind”,“Source”:“/DATA/Gallery”,“Target”:“/photoprism/originals”},“SkipMountpointCreation”:true},“/photoprism/storage”:{“Source”:“/DATA/AppData/photoprism/photoprism/storage”,“Destination”:“/photoprism/storage”,“RW”:true,“Name”:“”,“Driver”:“”,“Type”:“bind”,“Propagation”:“rprivate”,“Spec”:{“Type”:“bind”,“Source”:“/DATA/AppData/photoprism/photoprism/storage”,“Target”:“/photoprism/storage”},“SkipMountpointCreation”:true}},“SecretReferences”:null,“ConfigReferences”:null,“MountLabel”:“”,“ProcessLabel”:“”,“AppArmorProfile”:“docker-default”,“SeccompProfile”:“”,“NoNewPrivileges”:false,“WritableCgroups”:null,“HostnamePath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/hostname”,“HostsPath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/hosts”,“ShmPath”:“”,“ResolvConfPath”:“/var/lib/docker/containers/02017d85afccd8e41f35473916df6cfeda63ff20bc306da75016cdb58e5cb95b/resolv.conf”,“LocalLogCacheMeta”:{“HaveNotifyEnabled”:false}}

Do you envisage any kind of ‘Docker rescan’?

jlgarnier · June 2, 2026, 11:53am

Sorry @gelbuilding , my previous message was held by Aksimet. Please find the aswsers right above.

gelbuilding · June 3, 2026, 7:21am

Yes, that confirms this one was PhotoPrism.

I don’t think there is a safe “Docker rescan” command that will simply re-import container folders back into Docker’s active inventory. Docker normally relies on its own metadata/state, and if docker ps -a shows 0 containers while the old container folders still exist, I would treat that as Docker metadata/state corruption rather than a CasaOS UI issue.

The useful part is that the old container config still gives us the important recovery details:

Image:

photoprism/photoprism:250228

Container name:

/photoprism

Compose project:

photoprism

Original CasaOS compose path:

/var/lib/casaos/apps/photoprism/docker-compose.yml

Persistent data paths:

/DATA/Gallery/DATA/AppData/photoprism/photoprism/storage

So before reinstalling anything, I would check whether the original CasaOS compose file still exists:

sudo ls -l /var/lib/casaos/apps/photoprism/

and:

sudo cat /var/lib/casaos/apps/photoprism/docker-compose.yml

If that compose file still exists, recovery may be as simple as starting the app again from the original compose definition, while keeping the same /DATA/AppData/... and /DATA/Gallery paths.

I would not manually delete the old /var/lib/docker/containers folders, and I would not run any prune/cleanup command at this stage. The data looks recoverable, but I’d first verify each app’s original compose file and bind mounts before recreating anything.