jacobtomlinson

Can confirm the problem came back overnight and zfs mount -a resolved it. I don't usually test pre-releases but if you want to ping this thread when 7.2.1-rc.1 is available I'm happy to give it a go and feed back if it resolves things.

Got it, much appreciated!

Thanks for the fast response! When you say primary storage do you mean the array? My main array is using unraid, and my cache pool is using ZFS.

Since upgrading to 7.2.0 I've been having an intermittent write issue with one of my shares. I'm not 100% confident that it was caused by upgrading to 7.2.0, but it started happening the day after. I have a fix/workaround so wanted to share it here in case other folks run into it. I have a share which is set up with a cache pool and moves to my array overnight. After the mover completes I can no longer write to the share at /mnt/user/Share/... and I get an Invalid argument error when I try to do so. touch /mnt/user/Share/test # touch: cannot touch '/mnt/user/Share/test': Invalid argumentHowever I can still write to the array directly at /mnt/user0/Share and I can also write to the cache pool at /mnt/cache. I have no SMART or filesystem errors. The cache is a ZFS mirror. If I stop/start the array everything works as expected until the next night when the mover runs. When investigating the issue I noticed that the directory /mnt/cache/Share didn't exist. I'm not sure if it did exist before upgrading to 7.2.0, or if it did exist before the mover ran. My fix was to manually create that directory mkdir /mnt/cache/ShareMy suspicion is that the mover cleaned up this directory, and it needs to exist in order to write to the share through the cache. I also am guessing that stopping/starting the array caused this directory to be recreated. However, so far things have been working since I manually created the directory and remain working 24 hours later after the mover has been run.

I also just upgraded from 6.9.x to 7.0 (I know big jump) and am having the same issue. My template files are fine so that's not the issue. As @primeval_god says I've found that I can either delete and recreate the container, or I can update the container (for those that have an update available) and that resolves the issue. I notice that when the containers get recreated they get given some labels like `net.unraid.docker.managed=dockerman`. I wonder if these are missing on my old containers and that's what is causing the issue.