Hi everyone's,

I have just updated to 7.3.3 from 7.3.2 and at the restart i have lost 80% of my docker app.

The folder has remained but there is no app.

Can someone help me understanding if there is a way to restore them and why the got lost?

mordor-diagnostics-20261009-0721.zip

This doesn't appear to have been caused by the update itself, but by the RAM-DISK-Dockerlog plugin. Your appdata and your container templates should be safe, so you can get everything back.

What happened:

1. The plugin keeps Docker's container information on a RAM disk. It keeps a backup in appdata/containers_backup, but it only updates that backup when Docker starts or stops. Docker had been running since July 9, so the backup was from July 9.

2. When you rebooted for the update, Docker did not stop within the 90 second shutdown time-out (your Docker stop time-out is 180 seconds). The server forced the shutdown, so the plugin did not save a new backup.

3. On 7.3.3, the newer rsync refused the plugin's copy into appdata (refusing to follow a symlink owned by an untrusted user). The plugin then restored the old July backup.

4. Because of this, Docker only knows about your containers as they were in July. Any container that was installed or updated after July is missing, and the old entries fail with RWLayer ... is unexpectedly nil. The up-to-date copy was most likely overwritten by the plugin's periodic sync after the boot.

To fix it:

1. Remove the RAM-DISK-Dockerlog plugin. If you want to keep it, update it to version 2026.10.09 or later, which the author says fixes this on 7.3.3. Then reboot.

2. Go to Settings → Docker, set Enable Docker to No, and delete the Docker vDisk.

3. Delete the folder /mnt/user/appdata/containers_backup. If the plugin is still installed, it will otherwise copy the old data back into the new image.

4. Create a new Docker vDisk. I suggest a btrfs docker.img in /mnt/user/system/docker/. Then enable Docker.

5. Check that your custom Docker networks (for example yussnet and filebrowse) exist. If they do not, create them again before the next step.

6. Go to Apps → Previous Apps, select all your containers, and install them. They will use the same templates and the same appdata, so your settings and data are kept. Containers that you deployed outside the Docker page (for example with Portainer or compose) must be deployed again from their own definitions.

Also go to Settings → Disk Settings and set the Shutdown time-out higher than the Docker stop time-out, for example 240 seconds. Then a future reboot will not kill Docker before it stops.

7 minutes ago, JorgeB said:

This doesn't appear to have been caused by the update itself, but by the RAM-DISK-Dockerlog plugin. Your appdata and your container templates should be safe, so you can get everything back.

What happened:

1. The plugin keeps Docker's container information on a RAM disk. It keeps a backup in appdata/containers_backup, but it only updates that backup when Docker starts or stops. Docker had been running since July 9, so the backup was from July 9.

2. When you rebooted for the update, Docker did not stop within the 90 second shutdown time-out (your Docker stop time-out is 180 seconds). The server forced the shutdown, so the plugin did not save a new backup.

3. On 7.3.3, the newer rsync refused the plugin's copy into appdata (refusing to follow a symlink owned by an untrusted user). The plugin then restored the old July backup.

4. Because of this, Docker only knows about your containers as they were in July. Any container that was installed or updated after July is missing, and the old entries fail with RWLayer ... is unexpectedly nil. The up-to-date copy was most likely overwritten by the plugin's periodic sync after the boot.

To fix it:

1. Remove the RAM-DISK-Dockerlog plugin. If you want to keep it, update it to version 2026.10.09 or later, which the author says fixes this on 7.3.3. Then reboot.

2. Go to Settings → Docker, set Enable Docker to No, and delete the Docker vDisk.

3. Delete the folder /mnt/user/appdata/containers_backup. If the plugin is still installed, it will otherwise copy the old data back into the new image.

4. Create a new Docker vDisk. I suggest a btrfs docker.img in /mnt/user/system/docker/. Then enable Docker.

5. Check that your custom Docker networks (for example yussnet and filebrowse) exist. If they do not, create them again before the next step.

6. Go to Apps → Previous Apps, select all your containers, and install them. They will use the same templates and the same appdata, so your settings and data are kept. Containers that you deployed outside the Docker page (for example with Portainer or compose) must be deployed again from their own definitions.

Also go to Settings → Disk Settings and set the Shutdown time-out higher than the Docker stop time-out, for example 240 seconds. Then a future reboot will not kill Docker before it stops.

Thanks a lot JorgeB for the deep explanation, i have recover everything.
And thanks for pointing out the misconfigured Docker and System Shutdown, i do not remember to have change this somewhere in the past, but i have move the shutdown time-out to 240 has suggested.
Thanks again

Sorry, that one is on me. Only got around to power cycle for the release to check today. didnt have it on the radar that it might be an issue as its owned by root but the /mnt/ folders are nobody :/

5 minutes ago, Mainfrezzer said:

Sorry, that one is on me. Only got around to power cycle for the release to check today. didnt have it on the radar that it might be an issue as its owned by root but the /mnt/ folders are nobody :/

Seems not only your fault, my unraid was misconfigured so no problem :)