Permissions help - Writing via NFS, SMB W/X ok but unable to delete?

[NOTORIOUS VR]

I seem to have mucked something up somewhere permissions wise - Everything works as I think it should I can open/run the files/folders except when I go to delete files/folders via SMB (Windows) - it just doesn't delete. No errors, no complaining from Windows at all. It just doesn't do anything.

The scenario is as follows.

"Downloads" folder/share - ACL permissions are root/everyone > full, SMB permissions set in windows for the share to only have windows groups (everyone removed - not denied) to make sure that only authenticated domain users can access the share.

My user which in a group that has FULL access cannot delete it, but also neither can the administrator user (idmap'd to root)? I can delete it via ssh on napp-it. In the example below the folder I cannot remove is PC Games.

Another test: If I create a file/folder with an authenticated Windows user or even as root in ssh, I can delete the file/folder without issue (folder test below). It only seems to be an issue with files/folders created by another server/program accessing the share via NFS. This was not an issue before I started to mess with permissions.

ACL's seem to be correct:

root@batcavefs:/storage_z2/other/Downloads/Newsgroups# ls -Vd PC\ _\ Games/
drwxrwxrwx+  3 root     root           3 Mrt. 18 18:11 PC _ Games/
              user:root:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWc--s:fd----I:allow
root@batcavefs:/storage_z2/other/Downloads/Newsgroups# ls -Vd test/
drwxrwxrwx+  2 root     root           2 Mrt. 18 18:25 test/
              user:root:rwxpdDaARWcCos:fd----I:allow
              everyone@:rwxpdDaARWc--s:fd----I:allow

Clearly there is something I am missing somewhere.... but I cannot see it.

 

[gea]

I seem to have mucked something up somewhere permissions wise - Everything works as I think it should I can open/run the files/folders except when I go to delete files/folders via SMB (Windows) - it just doesn't delete. No errors, no complaining from Windows at all. It just doesn't do anything.

There may be three reasons that hinders a delete
- permission restrictions of any file below the folder
-> Reset permissions recursively to everyone=modify (Windows or napp-it)

- open files
-> restart service to close all open file handlers

- a file that is set to read only
-> set/reset readonly attribut recursively from Windows

 

[NOTORIOUS VR]

There may be three reasons that hinders a delete
- permission restrictions of any file below the folder
-> Reset permissions recursively to everyone=modify (Windows or napp-it)

The issue is that making a file/folder in windows (or by root users from napp-it shell) does not have this effect. So I do not see how it can be an ACL/permissions issue set by windows or napp-it server. As you can see above the ACL's are correct.

Only new files/folders made/copied by the program (NZBGET) from the server writing to the share via NFS has this problem.

- a file that is set to read only
-> set/reset readonly attribut recursively from Windows

I do not see this attribute set on the folder/files:

root@batcavefs:/storage_z2/other/Downloads/Newsgroups# ls -vd PC\ _\ Games/
drwxrwxrwx+  3 root     root           3 Mrt. 18 18:11 PC _ Games/
     0:user:root:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit
         /inherited:allow
     1:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /synchronize:file_inherit/dir_inherit/inherited:allow
root@batcavefs:/storage_z2/other/Downloads/Newsgroups# cd PC\ _\ Games/
root@batcavefs:/storage_z2/other/Downloads/Newsgroups/PC _ Games# ls -d *
Angry.Bunny.2.Lost.Hole.Update.1-PLAZA
root@batcavefs:/storage_z2/other/Downloads/Newsgroups/PC _ Games# ls -vd *
drwxrwxrwx+  4 root     root           4 Mrt. 18 18:11 Angry.Bunny.2.Lost.Hole.Update.1-PLAZA
     0:user:root:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /write_acl/write_owner/synchronize:file_inherit/dir_inherit
         /inherited:allow
     1:everyone@:list_directory/read_data/add_file/write_data
         /add_subdirectory/append_data/read_xattr/write_xattr/execute
         /delete_child/read_attributes/write_attributes/delete/read_acl
         /synchronize:file_inherit/dir_inherit/inherited:allow

It's as if there is some permission/ownership change that isn't reflected anywhere (that I know to look). Even looking at permissions via windows doesn't work on the files/folders created by the prog/server via NFS:

 

[NOTORIOUS VR]

OK even stranger now....

It doesn't happen with all folders created by the NFS write...

So maybe it is not a permissions issue after all and something else is happening? Maybe something is actually keeping the files/folders open (even though I never open anything)? Is there any tool to check if something is actively acting on the file/folder to help me with diag?

I ran the ACL script > Remove (recursive) and then modify (recursive), still these stubborn folders cannot be deleted:

I also reset the Windows permissions to have just the default of everyone@=full via root/admin user... nada:

The change is confirmed in napp-it SMB ACL as well:

Everything "seems" to be working/correct.... just some folders are acting strange when written via NFS only.

 

[gea]

There are two things

1. If you set a file readonly via SMB this is only respected via SMB and not visible in the ACL. You can disable only via SMB. Yoa can delete via console/WinSCP/mc as this attribute is SMB only.

2. The Solarish SMB server use always ntfs alike ACL with inheritance, just like real Windows. They are far superiour to basic Unix permissions like 755. But as ZFS is a Unix filesystem you can use old Unix permissions. In such a case ex when you use NFS3, ACLs are set to a ruleset that is as restrictive and - and this is important any inheritance settings are got deleted as this is not known with traditional Unix permissions.

This is why you see such permission problems quite often with dual use NFS + SMB. A solution is then to reset all ACL recursively with inheritance enabled. You can then set aclmode setting of the filesystem to restricted. This will hinder NFS to modify permission settings.

 

[NOTORIOUS VR]

A solution is then to reset all ACL recursively with inheritance enabled.

Hi Gea,

I thought so too - and I have done this as noted above but even after resetting the ACL's through napp-it I cannot delete these specific files/folders unless I am root on the napp-it server via ssh or via root-ssh on the other server that is connected to the share via NFS.

I can download 3 different things (each making new folders depending on the "group" I DL from), 2 show the same issue - the other does not. There is zero difference between them as far as I can tell.

I will try setting the aclmode to restricted though.

MfG

so I did two things, SMB = off via napp-it and then back on again and set again the permissions as I wanted them + aclmode = restricted and now it is working.

I will continue to monitor the issue with this and other servers using NFS, etc. It's just so strange that it wasn't effecting ALL files/folders equally.

Thanks for the help!