core updated the scale encountered permission issues

[sikailegend]

Hello gods.
I recently updated my NAS system from core to scale. Subsequently, when installing APPS, I found some permission issues: when giving APPS account and group permissions to folders (PLEX is used to read existing media files), there is a problem with not being able to give permissions. The error message is as follows. [EPERM] File system permissions on path /mnt/Media_disk prevent group applications from accessing path /mnt/Media_disk/media. This can be fixed by granting the above group execute permissions on the path. /mnt/Media_disk.
Thanks for the help and waiting for your reply

 

[indivision]

What are the permissions on /mnt/Media_disk ?

 

[anodos]

Yeah, this looks like one of those all-too-common cases where chmod 770 (or similar command) has been run from the shell. There are unfortunately a significant number of youtube influencers who don't understand permissions on Unix and recommend doing this (it basically breaks access to all data on the pool for non-root users).

This check was specifically added as a response to this (to help end-users diagnose broken permissions).

 

[indivision]

Most likely.

I also saw another edge case. If you do a clean re-install of the OS (some may do when switching from Core to Scale) you can lose the User/Group accounts you previously used on your pool. Then, those ID numbers are treated as "unknown" by the OS. Or, in theory if they have the same ID number, they could get unexpectedly applied to different, newly created users/groups with different permissions.

 

[anodos]

Most likely.

I also saw another edge case. If you do a clean re-install of the OS (some may do when switching from Core to Scale) you can lose the User/Group accounts you previously used on your pool. Then, those ID numbers are treated as "unknown" by the OS. Or, in theory if they have the same ID number, they could get unexpectedly applied to different, newly created users/groups with different permissions.

That is expected. Filesystem permissions are always based on uid / gid. Conversion of ids to names and whatnot is through NSS, which will go through whatever NSS modules are loaded (by default just your typical /etc/passwd, /etc/group files). That said, it won't cause permissions errors on the pool mountpoint because we default to 755 and root:root there. The only way to get different permissions on pool mountpoints is to modify from shell.

 

[indivision]

we default to 755 and root:root there.

That's how I noticed it in my case. I was double-checking the mountpoint perms and found one that had a no-longer-used group as owner instead of root. It all still worked fine as the permissions weren't bad. But, I could see how that might throw someone off. It's not a bug. Just something users need to be aware of, imo.

Was there a time when you could change those perms outside of shell? I can't remember for certain. But, I seem to remember a version of the Core train that did allow changing the mountpoint perms in GUI. I think my case might have been a remnant of that.

 

[anodos]

That's how I noticed it in my case. I was double-checking the mountpoint perms and found one that had a no-longer-used group as owner instead of root. It all still worked fine as the permissions weren't bad. But, I could see how that might throw someone off. It's not a bug. Just something users need to be aware of, imo.

Was there a time when you could change those perms outside of shell? I can't remember for certain. But, I seem to remember a version of the Core train that did allow changing the mountpoint perms in GUI. I think my case might have been a remnant of that.

We started restricting this around FreeNAS 11.2 -> 11.3 because users would often make changes at root level that would knock themselves out of production.

 

[SudoAdminRoot]

Hello guys, very nice talk, and is there any ex-post solution for newbies who have screwed there pool permissions like this? (but I don't remmeber following any youtuber influencers)

 

[indivision]

Hello guys, very nice talk, and is there any ex-post solution for newbies who have screwed there pool permissions like this? (but I don't remmeber following any youtuber influencers)

You could re-apply the chmod command so that it gives execute privileges to the parent folders: chmod 771

 

[SudoAdminRoot]

Unfortunately when I try to mess with chmod, it says (771 specificaly as well):

 

[anodos]

Unfortunately when I try to mess with chmod, it says (771 specificaly as well):

View attachment 59156

If this is Core, what is output of getfacl /mnt/pool1? Scale, nfs4xdr_getfacl /mnt/pool1?