SMB shares, if you remove delete permission, users cannot rename or move files

[ollieMSQ]

Hi there so as the title of this post goes on. i am having some issues. we have everything set up but when we remove the user permissions to delete and delete subfolders, the users cannot move or rename any files / folders within the shares.

please note that these changes are being made within the share management on the server side. NOT in the web portal aspect to freenas.

Has anyone else encountered this issue and if so does anyone have any insight how to work around this.

Many thanks.

 

[SweetAndLow]

Isn't a rename and move the same thing as delete? Maybe there is a different way to do this.

Sent from my Nexus 5X using Tapatalk

 

[anodos]

Hi there so as the title of this post goes on. i am having some issues. we have everything set up but when we remove the user permissions to delete and delete subfolders, the users cannot move or rename any files / folders within the shares.

please note that these changes are being made within the share management on the server side. NOT in the web portal aspect to freenas.

Has anyone else encountered this issue and if so does anyone have any insight how to work around this.

Many thanks.

I believe that currently in ZFS on FreeBSD the "write data" permission implies "delete" and "delete child". Nothing actually happens if you remove the ACE for "delete" and "delete child". On the other hand if you remove "write data", then you lose the ability to delete, rename, move, etc. See bug report here: https://bugs.freenas.org/issues/24130

On the third hand, if you set an explicit deny ACE for "delete" and "delete child", then you lose the ability to move and rename files. This is because (I might be wrong on this) the permission prevents unlink(), which is part of the rename / move process [even if the rename() system call is used, the user needs the permission to unlink the destination if it already exists].

So where does that leave us? Is it a bug? Is it a feature? Well, it's certainly a difference between NFSv4 ACLs as implemented in FreeBSD and Windows ACLs. I believe a workaround is to use the ACL_XATTR VFS object in Samba. I've covered this in slightly more detail here: https://forums.freenas.org/index.php?threads/windows-ad-share-permission.54764/

 

[ollieMSQ]

i guess you could say that but under the effective permissions tab ( see the image below - this is just for reference not my actual effective permissions)

i would have thought that move / rename would be classed as the "change permissions" as oposed to "delete" and "delete subfolders and files"

i am trying different configurations and getting the end users to test. i will post feedback upon finding any.

 

[ollieMSQ]

I believe that currently in ZFS on FreeBSD the "write data" permission implies "delete" and "delete child". Nothing actually happens if you remove the ACE for "delete" and "delete child". On the other hand if you remove "write data", then you lose the ability to delete, rename, move, etc. See bug report here: https://bugs.freenas.org/issues/24130

On the third hand, if you set an explicit deny ACE for "delete" and "delete child", then you lose the ability to move and rename files. This is because (I might be wrong on this) the permission prevents unlink(), which is part of the rename / move process [even if the rename() system call is used, the user needs the permission to unlink the destination if it already exists].

So where does that leave us? Is it a bug? Is it a feature? Well, it's certainly a difference between NFSv4 ACLs as implemented in FreeBSD and Windows ACLs. I believe a workaround is to use the ACL_XATTR VFS object in Samba. I've covered this in slightly more detail here: https://forums.freenas.org/index.php?threads/windows-ad-share-permission.54764/

 

[ollieMSQ]

thank you for this, i will read up on the links you provided.

 

[anodos]

Isn't a rename and move the same thing as delete? Maybe there is a different way to do this.

Sent from my Nexus 5X using Tapatalk

If you're moving files between datasets, then FreeNAS performs cp then rm on the file or directory. If it's in the same dataset, it simply uses rename(). Once you add SMB on top of it ¯\_(ツ)_/¯ I don't want to think that much right now.

 

[ollieMSQ]

its not from the backend we are trying to move files. its just the generic users we are trying to get it to work for thats all. ive got a feeling that because of the way the delete permissions and the way when you delete a file works its probably not doable.

Thank you for all your input.

 

[anodos]

its not from the backend we are trying to move files. its just the generic users we are trying to get it to work for thats all. ive got a feeling that because of the way the delete permissions and the way when you delete a file works its probably not doable.

Thank you for all your input.

Configuring "acl_xattr" with "ignore system ACLs as described in the above-linked thread should do what you need it to do. The primary caveat is that this only works if the dataset is exclusively being accessed through Samba (it will leave the backend permissions wide open).