Hi,

I am hoping someone could help me with the issues I am having.

It seems after a certain period oftime unraid loses the ability to write to some of the shares in my array. Trying mkdir (mkdir: cannot create directory ‘test1’: Invalid argument) or uploading files results in errors.

However after rebooting everything returns to normal for a short while (maybe a hour or 2) before reverting to a state of not being able to write to the disk.

For reference I cant write data to these shares below but not any other shares on the system.

appdata

domains

isos

system

I have upload diagnostics below, could anyone help me to try and figure out whats happening on the server.

Thanks

monterrey-diagnostics-20251103-1042.zip

This is a known issue, it happens for some users with ZFS as primary storage. It should be fixed for 7.2.1, as a workaround for now, if you type zpool mount -a it should resolve it.

Hi, Thanks for the quick reply.

I tried running the commands you mentioned but it came back as unrecognised.

root@Monterrey:/mnt/user/backups# zpool mount -a

unrecognized command 'mount'

sorry, it's zfs mount -a

@JorgeB

That worked perfectly, thank you for taking the time to answer my post.

On 11/3/2025 at 12:49 PM, JorgeB said:

This is a known issue, it happens for some users with ZFS as primary storage. It should be fixed for 7.2.1, as a workaround for now, if you type zpool mount -a it should resolve it.

Upgraded to 7.2 and had that too. My main array is a "standard" unraid array, but yes, my cache is ZFS Z1.
A restart and typing "zfs mount -a" solved it.

I'm surprised something that bad hasn't been found during beta/rc. I mean something as basic as creating a folder...

1 hour ago, denishay said:

I mean something as basic as creating a folder...

It only happens for some users after the mover runs and is unable to destroy the dataset correctly. Before finding out what the issue was, I tried for a week to duplicate the issue and couldn't.

7.2.1-rc.1 is out, and it should resolve this issue, please retest.

On 11/7/2025 at 11:29 PM, JorgeB said:

7.2.1-rc.1 is out, and it should resolve this issue, please retest.

i just updated. Will let you know. Thanks for your patience and dedication!!

On 11/7/2025 at 11:29 PM, JorgeB said:

7.2.1-rc.1 is out, and it should resolve this issue, please retest.

just to confirm, the issue is indeed fixed. I am experiencing networking issues though since the migration to 7.2 (random "disconnections" from VMs or even console/ssh). Still investigating that and eliminating variables as much as possible before reporting

Oh, bless you (and bless Google for leading me here)!

I was pulling my hair out all morning trying to get one of my docker containers to work... turns out it was trying to write to a share affected by this issue. I, also, have a "standard" array, but a ZFS cache. I was able to write directly to the disk (i.e. /mnt/disk4/data) but not through the "user" FUSE path (i.e. /mnt/user/data).

Hi all,

Had a bad surprise this morning with 7.2.2 (main stable, no beta or rc): it seems that in some circumstances, the datasets on ZFS mounts are still not behaving properly.

I had by accident created a folder under /mnt/user

This created a share of the same name. Fine. Shouldn't be an issue I thought

When I realized that the folder path was not what I wanted (I wanted that under /mnt/user/data/<fodlername>), I thought I would just have to delete the content, then proceed to delete the share.

Step 1: delete content: no worries on that front

Step 2: share deletion. That's where things started to be weird.

• tried the "normal" Delete checkbox under the share management page -> didn't work. back to share management page and hare still here and not deleted

• saw that for some reason (system default seem to be to have shares on cache), /mnt/cache contained and empty folder named <foldername> - tried to delete that as a root user with Midnight Commander, using rmdir, etc. --> no success either. Keep getting a "resource busy" error

• Then I thought, as my cache is a ZFS1 dev, that meant that /mnt/cache contained a DATASET named <foldername>. Tried using the ZFS Master plugin to destroy the <foldername> dataset... a "no permissions" error showed up

And... that's where I recalled my recent issues on this ZFS cache when upgrading to 7.2

Sure enough, I open an ssh session as root, type "mount -a".... and I could now just delete the folder without any issues.

Are we in an "edge" use case which wasn't covered by the recent "fix"?

I solved my immediate problem, but I'm bound to not be the only one ending up experiencing that

So the folder was a dataset right? If you haven't rebooted yet, please post the diagnostics.