Good morning.

I need help. I replaced a drive following Unraid Drive Replacement and Upgrade | Easy Steps for Seamless Transition - YouTube.

When I restarted, Docker failed to start and the log shows:

ov 12 08:30:14 NAS ool www[10059]: /usr/local/emhttp/plugins/dynamix/scripts/emcmd 'cmdStatus=Apply'
Nov 12 08:30:14 NAS emhttpd: Restarting services...
Nov 12 08:30:15 NAS emhttpd: shcmd (72): /etc/rc.d/rc.samba reload
Nov 12 08:30:15 NAS kernel: ata9: limiting SATA link speed to 1.5 Gbps
Nov 12 08:30:15 NAS emhttpd: shcmd (76): /etc/rc.d/rc.avahidaemon reload
Nov 12 08:30:15 NAS avahi-daemon[2348]: Got SIGHUP, reloading.
Nov 12 08:30:15 NAS emhttpd: shcmd (79): /usr/local/sbin/mount_image '/mnt/user/system/docker/docker.img' /var/lib/docker 50
Nov 12 08:30:16 NAS kernel: loop3: detected capacity change from 0 to 104857600
Nov 12 08:30:16 NAS kernel: BTRFS: device fsid ea2c29c8-9238-4186-8557-955760ffe8be devid 1 transid 1294311 /dev/loop3 (7:3) scanned by mount (10485)
Nov 12 08:30:16 NAS kernel: BTRFS info (device loop3): first mount of filesystem ea2c29c8-9238-4186-8557-955760ffe8be
Nov 12 08:30:16 NAS kernel: BTRFS info (device loop3): using crc32c (crc32c-lib) checksum algorithm
Nov 12 08:30:16 NAS nfsrahead[10490]: skipping non-NFS device btrfs-3
Nov 12 08:30:16 NAS kernel: BTRFS error (device loop3): parent transid verify failed on logical 56172773376 mirror 1 wanted 1294306 found 1294319
Nov 12 08:30:16 NAS kernel: BTRFS error (device loop3): parent transid verify failed on logical 56172773376 mirror 2 wanted 1294306 found 1294319
Nov 12 08:30:16 NAS kernel: BTRFS error (device loop3): open_ctree failed: -5
Nov 12 08:30:16 NAS root: mount: /var/lib/docker: can't read superblock on /dev/loop3.
Nov 12 08:30:16 NAS root:        dmesg(1) may have more information after failed mount system call.
Nov 12 08:30:16 NAS root: mount error
Nov 12 08:30:16 NAS emhttpd: shcmd (79): exit status: 1

How can I fix this?

Thank you for reading.

Pat

It's always best to post the full diags, but based on that, the docker image is corrupt, delete and recreate it:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#re-creating-the-docker-image-file

Then:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#reinstalling-docker-applications

Also see below if you have any custom docker networks:

https://docs.unraid.net/unraid-os/troubleshooting/common-issues/docker-troubleshooting/#restoring-docker-custom-networks

1 hour ago, pglamb said:

I replaced a drive following

That video seems to have some misconceptions about rebuilding.

No need to move data from the drive to be replaced, it will be rebuilt on the new drive.

And moving the data from the drive will not affect how long it takes to rebuild. He sort of realizes this since even after moving all the "data" from the drive, he says it has to rebuild all the data on the drive. And it does because the bits from all the removed files are still on the disk, and has to be rebuilt since these bits are still all part of parity.

Simply recreating docker.img should fix your problem as mentioned, but I have to wonder if your docker.img is configured to be on the array and not on cache or other pool.

Might be a good idea to

Attach Diagnostics ZIP to your NEXT post in this thread

so we can take a look and see if there are some other things that need attention.

11 minutes ago, trurl said:

No need to move data from the drive to be replaced, it will be rebuilt on the new drive.

And moving the data from the drive will not affect how long it takes to rebuild.

This sort of maintenance is built-in to Unraid, always has been, and is a direct result of the way parity works. No need to get unbalanced or any other plugin involved.

1 hour ago, trurl said:

This sort of maintenance is built-in to Unraid, always has been, and is a direct result of the way parity works. No need to get unbalanced or any other plugin involved.

Thank you for the suggestions. I've uploaded my diagnostics.

I've also recreated the docker file as suggested and am working to reinstall containers.

nas-diagnostics-20261112-1757.zip

The array is fine: the rebuild completed without errors and all disks look healthy, so recreating the docker image was the correct fix.

Most likely cause: your docker.img was on the array (the system share isn't set to use a pool), and the video you followed moves data off the disk before replacing it. If docker.img got moved while the Docker service was running, the copy ends up inconsistent, and that matches the error you were getting. The rebuild itself would not cause this.

To avoid this in the future, and for better performance, I would move the docker image and appdata to the cache pool. Note that the new docker.img was again created on the array, and appdata is set to cache only but it also has files on disk1 and disk2:

- Settings > Docker and Settings > VM Manager: disable both services

- Shares: set system and appdata to primary storage cache, secondary storage array, mover action array -> cache

- Run the mover from the Main page and wait for it to finish

- Click "Compute" for those shares to confirm everything is now on cache, then set secondary storage to none

- Re-enable the Docker and VM services

Since you are reinstalling the containers, you can do this first, then recreate the docker image so it's created on the pool. Use Apps > Previous Apps to reinstall them with the same settings.

Also, always stop the Docker and VM services before moving those shares, with the mover or any other tool. And as already mentioned, you don't need to move data off a disk before replacing it, Unraid rebuilds the contents to the new disk.

Unrelated: the syslog is being spammed with ata9 reset errors. That port has no detected device. If something is connected to it, check or replace the SATA cable, or disconnect the cable if nothing is supposed to be there.