Guest Share needs password unless I change root dataset permissions, which you can't, but I did?

[Paul5]

Version:
TrueNAS-12.0-U6.1

I'll try to make this coherent.
Media Dataset viewed on smb 1 players with guest (no password) required, until a ZFS change.
I'm converting to ZFS encryption from Geli so I created a ZFS encrypted disk and copied the media files and all permissions as per the original Geli one which works. Testing purposes > Root Dataset (Archive) > Media Dataset (Media_Backup) Problem, requires password even though it's guest.

Everything works except it asks for a password on trying to access 'Media_Backup' from the player. The only difference is the the Root Dataset permissions. On the guest working Geli disk it's 775 but on the ZFS it's 770 (unchangeable) but via the ftp client I can and have changed it to 775 and it worked but it defaulted back to 770 untill I rebooted and 775 sticks.

I have no clue? so what effects does it have in changing the ZFS encrypted root dataset to 775 for all my other geli disks are 775.

If I shouldn't or should go back to Root 770 how do I access the media files without password prompt.

 

[anodos]

Perhaps an application / client is mucking with permissions there. There are strict path checks on the internal APIs that middleware uses to prevent changes to root level dataset permissions.

770 often breaks permissions because users won't be able to traverse that path component.

 

[Paul5]

Perhaps an application / client is mucking with permissions there. There are strict path checks on the internal APIs that middleware uses to prevent changes to root level dataset permissions.

770 often breaks permissions because users won't be able to traverse that path component.

I have no idea what any of that means and your 770 reference is the default.

 

[anodos]

I have no idea what any of that means and your 770 reference is the default.

The permissions editor only shows what is currently set on-disk. When a new pool is created, the root-level dataset has permissions of 755 which allows users and processes to access data on the volume.

If /mnt/Archive is owned by root:wheel, and you set permissions of 0770 on that path via SSH, FTP, SMB, NFS, etc, then only root and members of the group "wheel" will be able to access any paths below /mnt/Archive (for example /mnt/Archive/media).

If you share a path over SMB for instance, an SMB client may request to change permissions on the path, same for FTP and other file-sharing protocols. For that matter, if you're granting SSH access some SSH client may also be able to alter permissions there. On the backend, TrueNAS will never change permissions on /mnt/Archive.

 

[Paul5]

The permissions editor only shows what is currently set on-disk. When a new pool is created, the root-level dataset has permissions of 755 which allows users and processes to access data on the volume.

755? I'm testing two disks and the default TN setup for root dataset is 770 root wheel. I think you're confusing 755 for 770, Also there is no permissions editor for the root dataset. IT's greyed out by default.

If /mnt/Archive is owned by root:wheel, and you set permissions of 0770 on that path via SSH, FTP, SMB, NFS, etc, then only root and members of the group "wheel" will be able to access any paths below /mnt/Archive (for example /mnt/Archive/media).

770 and root wheel is the default disk setup by TN. You get no options and it's greyed out on the GUI, Hence I changed it to 775 on the FTP client giving 'Other' write, execute access which in turn give guest access. But is this safe/right.

If you share a path over SMB for instance, an SMB client may request to change permissions on the path, same for FTP and other file-sharing protocols. For that matter, if you're granting SSH access some SSH client may also be able to alter permissions there. On the backend, TrueNAS will never change permissions on /mnt/Archive.

Why won't it allow change in the backend like all other datasets if you can still change it remotely, It doesn't make sense. Why are all the root datasets permissions greyed out, again, if you can change remotely.

So is it safe or right to leave the root dataset Archive as 775 for guest access or should I change the root owner and group to something else with 770. If so, what.

Having read somewhere that with TN and ZFS you should create datasets and not use the root dataset to store data. Would the data be at risk on the root dataset if I leave it as 775.

If all you say is so, I still do not understand why root Datasets cannot be changed from the GUI. It's intentional but why.

 

[anodos]

770 and root wheel is the default disk setup by TN. You get no options and it's greyed out on the GUI, Hence I changed it to 775 on the FTP client giving 'Other' write, execute access which in turn give guest access. But is this safe/right.

No. This is not the default permissions set up on new dataset creation. The default is 755 unless unexpected system changes have been made on your end or if this is a pool originating from a different OS. It's greyed-out because the backend does not permit editing these permissions. This does not prevent users from manually doing it through shell commands or a remote NFS / SMB / FTP / etc client changing it if for some reason you have exposed it through a filesharing protocol.

It is not permitted because many users kept recursively changing permissions on a root level to things like 770 and breaking all their apps, jails, etc, etc.

 

[Paul5]

No. This is not the default permissions set up on new dataset creation. The default is 755 unless unexpected system changes have been made on your end or if this is a pool originating from a different OS.

I wanted to say you're wrong for I'm the only one and have not changed from your 755 to 770. So I grabbed an old pc with an IDE HDD and clean install, it created it as 755, passworded it as mine to see but even after reboot it remained as 755. Ok, so 755 root wheel is the default.

The first thing that popped into my head was a bug I reported months ago on an upgrade that I can write to unmounted ZFS datasets over ftp, though unrelated my head is in overdrive now to try and recall anything. As it stands I have two ZFS encrypted disks and both used to be Geli encrypted, detached and recreated as ZFS encrypted with (somehow) 770 root filesystem permissions, now 775.

In any case I'm fine with 755/775 both let me do what I need and I just allowed group write from the default. I still have a few Geli encrypted disks to do over the coming months and will note before and after changes. Till then, I'm done.

Thanks