May 12, 20251 yr Hi everyone, I've been having an issue for quite some time now: whenever I try to shut down the array, for example, to perform a reboot, it's not possible. I keep getting the message "retry unmounting disk share(s)" indefinitely. This has been happening since the 6.12 versions and continues with the current version. Just now, when I started the update to 7.1.2, I ran into the same problem again. What I notice is that there are write accesses to the cache with a couple of kilobytes every few seconds, but I have no idea where they're coming from. Before shutting down the array, I always stop the Docker and VM services and unmount any mounted SMB shares. At this point, I genuinely have no clue what else could be accessing it. As far as I'm aware, I don't have any open terminal sessions either. Is it possible to trace anything using the diagnostics? storage-diagnostics-20250512-1325.zip
May 12, 20251 yr Community Expert Disable Docker and VM service and reboot in safe mode, start the array and see if it stops, if yes, retest again after booting in normal mode to rule out a plugin issue, leave the services still disabled, if still OK enable one of the services and retest, then the other, note that if the issue happens with the docker service enabled only, you may need to try enabling one or a few containers at a time to find the culprit.
May 14, 20251 yr Author Sorry for the late reply, but I’ve been trying to further trace the error. So… the issue doesn’t always occur. After updating to 7.1.2, everything ran fine the day before yesterday and yesterday. In the evenings, I tried stopping the array a few times, which worked without any issues. Today I tried the same thing again, and once more I can’t stop the array. The error is the same error as before. I’m not sure how to trace the problem if it can’t be reliably reproduced. It seems like the error only occurs after a few days. Every few seconds (around every 2 to 5 seconds), I see write operations on the cache lasting about 2 seconds, with a throughput of about 300-400 KB/s each time. But as far as I know, the cache shouldn’t still be in use. Tried the following, but nothing: root@Storage:~# losetup NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop1 0 0 1 1 /boot/bzmodules 0 512 /dev/loop0 0 0 1 1 /boot/bzfirmware 0 512 Tried that, but nothing, no result: root@Storage:~# lsof /mnt/cache storage-diagnostics-20250514-1915.zip
May 14, 20251 yr Community Expert Solution 12 minutes ago, domori said: the issue doesn’t always occur. This may make it more difficult to track down, but looking at the diags, I see that you are suing a docker folder with the native drive, the array is stopped so cannot see where that share resides, but I assume it's one of the zfs pools, that is known to cause issues, personally I would recommend using a docker image, but if you prefer the folder, delete the old one and change the driver to overlay2: https://docs.unraid.net/unraid-os/release-notes/7.0.0/#add-support-for-overlay2-storage-driver
May 15, 20251 yr Author Great, thanks for the heads-up. The thing with the overlay driver completely slipped past me. I’ve made the changes, deleted the directory, and pulled the containers again. I’ll keep an eye on it over the next few days.
May 17, 20251 yr Author As of now, it still appears to be working, so I'll mark that as solved. Thanks a lot JorgeB! Tried shutting the array down a couple of times over the last days and it worked every time. So I'll stop that now and I guess I'll see whether or not that was the final fix when I'm updating the next time.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.