Leaderboard

This seems to have fixed the issue.

Very interesting. To fix, open a Terminal window and type: echo 'shfsExtra="-o default_permissions"' > /boot/config/extra.cfg Then you must Stop/Start array. Also this will persist across reboots, hence to undo you must delete the file. This is a mount option that tells FUSE to let the kernel handle file system permissions. This used to be how FUSE worked by default and somewhere along the line it got changed, probably in transition from FUSE v2 to v3. This bug will get fixed in Unraid OS 6.10 where we can have a little beta testing before wider deployment.

I don't see the call trace specific to this issue in your log files.

@limetech Seems like a bug with shfs itself: root@MediaStore:/mnt/user/Downloads# echo x > a root@MediaStore:/mnt/user/Downloads# chmod 600 a root@MediaStore:/mnt/user/Downloads# ls -l a -rw------- 1 root root 2 Mar 23 21:44 a root@MediaStore:/mnt/user/Downloads# ls -l /mnt/cache/Downloads/a -rw------- 1 root root 2 Mar 23 21:44 /mnt/cache/Downloads/a root@MediaStore:/mnt/user/Downloads# cat a x root@MediaStore:/mnt/user/Downloads# su nobody -s /bin/sh nobody@MediaStore:/mnt/user/Downloads$ cat a x nobody@MediaStore:/mnt/user/Downloads$ cat /mnt/cache/Downloads/a cat: /mnt/cache/Downloads/a: Permission denied nobody@MediaStore:/mnt/user/Downloads$ echo y > a nobody@MediaStore:/mnt/user/Downloads$ cat a y I hope this is not directly caused by Limetech's stance that Unraid is an appliance and should only have the root user. As this can cause breakage with NFS shares, ransomware protection and general stuff and use cases that expect file permissions to protect stuff