My mover runs at 3.40am every morning and the appdata backup happens at 1am Sunday. The app data backup seems to trigger the problem each week when it runs (it errors out since it cant create folders) but I don't understand why since the mover runs 2 hours later

Actually think I found the problem. I also run duplicacy, which backs up my backup share on Sundays at 2am but we just switched over to daylight savings time a few weeks ago in Australia. My suspicion is that duplicacy is actually trying to run the backup at 1am since they haven't corrected for daylight savings time, which is the same time as my appdata backup. I've changed the schedule so let's see if it happens next week

Edited October 18, 2025Oct 18 by rama3124
Typo

I am having this same problem. Trying to create a folder in my /mnt/user/media/backup/ directory via Syncthing failed with invalid argument -- I ssh'd into the server, same error. I tried to create via the Unraid file browser and total commander and also can't create the directory.

Running 7.2.0 rc2 and the share is configured to write to a ZFS cache before moving to array.

Oct 28 20:55:39 Hippo shfs: /usr/sbin/zfs create 'shorty/media' 2>&1

Oct 28 20:55:39 Hippo shfs: cannot create 'shorty/media': dataset already exists

hippo-diagnostics-20251028-2057.zip

Definitely feels like some kind of bug. Upon further investigation this basically caused all of my docker containers to be unable to create new folders. This is a new problem and resolved itself when a stopped/restarted my array. Could be related to mover but utilizing mover while file operations are in progress shouldn't break the system.

Syslog had already rottated, so can't see the beginning of the issue, if it happens again, try getting the diagnostics immediately.

I continue to have this pop up on one of my servers. Have disabled all backup plugins/services and switched from SABnzbd to NZBget (on a hunch that didn't turn out to be true. Still think it may be tied to unpacking files and will continue to try and confirm). It happens overnight and then sometimes during the day. Haven't caught it as it is first happening but trying to keep a closer eye on it so I can provide diagnostics. Certainly appears to be tied to mover in some way, but can't confirm that.

Yeh this didn't fix my problem, it's still happening at the same time every week

On 10/19/2025 at 4:33 AM, rama3124 said:

Actually think I found the problem. I also run duplicacy, which backs up my backup share on Sundays at 2am but we just switched over to daylight savings time a few weeks ago in Australia. My suspicion is that duplicacy is actually trying to run the backup at 1am since they haven't corrected for daylight savings time, which is the same time as my appdata backup. I've changed the schedule so let's see if it happens next week

My

I believe there's an issue here, but I've been trying to duplicate it for over a week without any success, hoping someone can find the steps needed to reproduce.

I still haven't been able to reproduce, but I think I have a better understanding of what is happening:

• when the mover finishes running on a zfs stored share and the share is empty, it will do a zfs destory pool/share

• when this happens, ZFS checks for open files; if there aren't any, it first does a zfs unmout, then a zfs destroy.

• in this case, the unmount is being done, i.e., nothing should be using the dataset, but then the destroy still fails, leaving the dataset unmounted.

Before, I believed that Unraid automatically did a zfs mount for that datset if the destroy failed, looking into why it's no longer doing that with LT, in the meantime, if you have a chance to test in safe mode or without any plugins that could cause issues with opens files, like caches dirs, Dynamix active streams, etc, because the dataset getting unmounted but then failing to destroy should never happen in normal use, and that's the part I've been unable to duplicate.

28 minutes ago, JorgeB said:

I still haven't been able to reproduce, but I think I have a better understanding of what is happening:

• when the mover finishes running on a zfs stored share and the share is empty, it will do a zfs destory pool/share

• when this happens, ZFS checks for open files; if there aren't any, it first does a zfs unmout, then a zfs destroy.

• in this case, the unmount is being done, i.e., nothing should be using the dataset, but then the destroy still fails, leaving the dataset unmounted.

Before, I believed that Unraid automatically did a zfs mount for that datset if the destroy failed, looking into why it's no longer doing that with LT, in the meantime, if you have a chance to test in safe mode or without any plugins that could cause issues with opens files, like caches dirs, Dynamix active streams, etc, because the dataset getting unmounted but then failing to destroy should never happen in normal use, and that's the part I've been unable to duplicate.

Thanks for looking into this. I just disabled Folder Caching and Active Streams. Will update on my results.

On 10/29/2025 at 2:54 AM, JorgeB said:

Syslog had already rottated, so can't see the beginning of the issue, if it happens again, try getting the diagnostics immediately.

Syslog is intact in this diagnostic file. I think you are on to something:

Oct 30 04:20:10 Hippo shfs: /usr/sbin/zfs destroy 'shorty/media' 2>&1

Oct 30 04:20:10 Hippo shfs: cannot destroy 'shorty/media': dataset is busy

hippo-diagnostics-20251031-0109.zip

1 hour ago, Fffrank said:

Syslog is intact in this diagnostic file.

Syslog in the diags starts from Oct 27 04:40:01, so it doesn't have those, but see my reply above; it appears to be the same issue.

On 10/29/2025 at 2:54 AM, JorgeB said:

Syslog had already rottated, so can't see the beginning of the issue, if it happens again, try getting the diagnostics immediately.

I don't know if it's been immediate but this problem just happened for me again.....

On 10/29/2025 at 2:54 AM, JorgeB said:

Syslog had already rottated, so can't see the beginning of the issue, if it happens again, try getting the diagnostics immediately.

don't know if it's been immediate but this problem just happened for me again.....

Just now, JorgeB said:

Syslog in the diags starts from Oct 27 04:40:01, so it doesn't have those, but see my reply above; it appears to be the same issue.

But this issue of not being able to create new folders started at some point on 10/30 during this instance.

Am having the same problem - AppdataBackup regularly fails to do so every few days. Can't manually create a new folder in the Backup share I'm using... Been going on for at least two weeks now

I have Folder Caching and Active Streams disabled and just had it happen again. cruzunraid-diagnostics-20251031-0924.zip

Thanks for testing. Hopefully LT can find a solution for this issue soon; meanwhile, the workaround is to do a zfs mount -a, you can even create a user script with that running horly, it won't cause any issues.

I am running into this same issue and it showed up for me in Nextcloud. I could no longer upload any new files or sync. The zfs command fixes it for me temporarily. Hopefully a fix comes soon.

LT believes they have found the problem, and it will be resolved for 7.2.1

Fwiw, I have the problem on my regular btrfs

17 hours ago, project___unraid said:

I have the problem on my regular btrfs

If you mean using btrfs as primary storage, it can't be the same issue, since btrfs doesn't use datasets. I recommend creating a new thread and posting the diagnostics.

Hello,

I have excactly the same problem since the upgrade from 7.1.4 to 7.2.0. Only "zfs-cache -> array" shares are affected. I can read but not write to the affected folders

The command "zfs mount -a" solves the issue until the next day (when mover is finisished).

This must be a bug in Unraid 7.2.0 and hopefully will be resolved soon ...

Same here - It's been happening since the 7.2 beta and I hadn't previously found much reported online. Glad it's not just me. Impacts any share on my ZFS Cache that has the mover set to Cache->Array. Previously only a reboot would fix it. I didn't know the mover was potentially the trigger. I ran the command mentioned above "zfs mount -a" and that seems to have fixed it (temporarily?) This was mainly noticeable on my Downloads share/Dataset that would become unwritable by all apps and via SMB.

It is 100% related to zfs cache pools. I have 3 of them, and my solution was to reassign one of my shares to one of the other pools - something I had been meaning to do anyway.

Another work around would be to add a userscript which executes "zfs mount -a" periodically or, if you want to get advanced, after the mover executes.

The last info I have is that LT was planning to release a 7.2.1-rc.1 with this and some other fixes this week. This would allow the affected users to confirm it resolves the issue, since I and LT cannot reproduce it, and not for a lack of trying on my part, and if all looks good, then release 7.2.1 stable a week or so later.

Having similar issues here as well, on 7.2. What happened to me is I added a new ZFS cache pool, then changed my shares to use the new cache pool. When mover runs, it remove the share folder which then causes the issues. I can manually create the folder again but mover just removes it on next run. I also tried to manually create the dataset but again mover kills it. The work around is to manually create the folder\dataset back after mover runs.