Haven't had this happen before. After a reboot some user shares are empty, all other shares work as expected. The data is on the pool, just not in user shares. My primary array is a zfs pool called primus.

ls /mnt/user/data/media => ls: reading directory '/mnt/user/data/media': Input/output error

cd /mnt/user/data/media/anime => actually goes into the folder

ls /mnt/user/data/media/anime => ls: reading directory '/mnt/user/data/media/anime': Input/output error

cd /mnt/user/data/media/test_ => No such file or directory (which is correct)

ls /mnt/user/data/backup => all folder/files are there. Even opened a few to be sure.

I'm unable to upload anything to /mnt/user/data/media/, but i can to /mnt/user/data/ or any other subfolders of /mnt/user/data/

ls /mnt/user/data/media/anime/[SERIES]/ => all folder/files are there. Even opened a few to be sure.

ls /mnt/primus/data/media => all folder/files are there. Even played them to be sure and I can upload/modify anything.

So /mnt/user/data/media and 1 level down shows empty, but 2 levels down it shows all files as normal.

All folders are set to nobody and drwxrwxrwx.

All other shares are working perfectly fine.

This behavior is both in the Unraid UI and on Samba shares.

I tried New Permissions on both shares and drives.

Disabled dockers and vm's just to rule them out.

Many reboots in between.

What am I missing here?

cloud9-diagnostics-20261103-1631.zip

Edited 1 hour ago1 hr by X4n

The data share exists on two pools, cache and primus, and /mnt/user/data/media shows both of them merged. You checked the primus side, but not the cache side. Please post the output of:

ls -la /mnt/cache/data/media

ls -la /mnt/cache/data/media/anime

zfs list -o name,mountpoint,mounted -r cache/data primus/data

Look in particular for a name that exists as a file on one pool and as a folder on the other, or for any error when listing the cache side. If the cache copy only has some leftover files or folders, move them to the same place on primus and the user share should list normally again.

Two other things from the diagnostics, not related to this problem:

- During the last scrubs, the four primus disks connected to the onboard SATA ports had repeated link resets, all at the same time. SMART for all disks looks fine, so check the power cables and any splitters feeding those disks. That is likely why the scrubs keep finding a checksum error. Once that is fixed, run zpool clear primus and another scrub, and confirm that it finishes with 0 errors.

- The docker pool reports 52 data errors, and it has no redundancy. Run zpool status -v docker to see the affected files. If they are only inside the Docker data, it is usually easiest to recreate it. A memtest would also be a good idea, since that pool and primus both have errors.