Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

Deny Delete in AFP Share - ACL Nightmare :(

Hi all


I am really at the end of my tether with this.

All I want to do is deny deleting files and folders in an AFP share.


I have tried with POSIX and ACL's but it just will not work!!!!!!!!!!


The share folder is 'Archive' on 10.8 Server. The client machines are 10.6.


I want the clients to be able to look at, add to but not delete files in the Archive.


Surely this isn't too much to ask!??!?


I add the 'Read Write' ACL on the Archive folder and deselect 'delete and delete subfolders and files' but then it doesn't allow a client acess at all!



What's going on?

Mac mini, OS X Mountain Lion (10.8.5), Server

Posted on Feb 18, 2014 4:44 PM

Reply
Question marked as Best reply

Posted on Feb 18, 2014 7:39 PM

You can not do this with a single ACE. Or at least I've never been able to. Here is how to resolve.


Please make sure you test this however. Remember that trying to overwrite is a delete and then a write. So if you deny delete, then you can not replace a file or folder with one of the same name. Also, renaming a file is also a delete. You will not be able to rename. Make sure you test this before putting into production to ensure you are getting the behavior you want.


You have a share point named Archive. You have a group called Archive_Users. The Archive_Users are allowed to read and write but NOT delete data in the Archive. Do do this, follow these steps:


1: Create a group called Archive_Users and place your users into the group.

2: Define your share point in File Sharing.

3: Edit to share point to add the group. Press the + button and start typing the group name. When it appears, set the permission to Read Write. You permission window should have 4 entries at this point. The everyone, the group (likely staff), and the owner (likely the server admin). Then the one you added. The bottom three are POSIX, the final one is an ACE.

4: Now, you need to get your hands dirty and create a custom ACE. Server.app does not allow you to use the Deny rules so break out Terminal.

5: I will assume the Archive folder is in this path /Shares/Archive. First get a list of the folder's ACL using:


ls -le /Shares/Archive


It should like like the following:


drwxr-xr-x+ 2 carbon wheel 68 Feb 18 22:27 Archive

0: user:_spotlight inherited allow list,search,file_inherit,directory_inherit

1: group:archive_users allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity,file_inherit,directory_inherit


6: Now you must add your deny rule. Use the following command:


chmod +a# 2 "group:archive_users deny delete,file_inherit,directory_inherit" /Shares/Archive


The syntax here is to add (+a) an ACE at index 2 (# 2), an ACE for the group archive_users that states the group can no delete any file or folder and this is inherited all the way down.


7: If you have content in the folder already, be sure to propagate the permissions.

8: Test, test, test.


Remember, the deny rules can have some odd effects. As mentioned, I can think of the renaming and the overwrite as possible deterrents.


A possible alternative is to not give everyone read write access to the Archive. It might be more sane to define two groups. The first groups, Archive_admins, is a subset of users who are entrusted with moving data to archived status. The second group, Archive_users, is the rest of the team and they have read only access, allowing them to pull data but not edit the archive. This allows you to use two simple ACEs in Server.app: Archive_admin = read/write and Archive_users = read.


R-

Apple Consultants Network

Apple Professional Services

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

2 replies
Question marked as Best reply

Feb 18, 2014 7:39 PM in response to De Baron 2009

You can not do this with a single ACE. Or at least I've never been able to. Here is how to resolve.


Please make sure you test this however. Remember that trying to overwrite is a delete and then a write. So if you deny delete, then you can not replace a file or folder with one of the same name. Also, renaming a file is also a delete. You will not be able to rename. Make sure you test this before putting into production to ensure you are getting the behavior you want.


You have a share point named Archive. You have a group called Archive_Users. The Archive_Users are allowed to read and write but NOT delete data in the Archive. Do do this, follow these steps:


1: Create a group called Archive_Users and place your users into the group.

2: Define your share point in File Sharing.

3: Edit to share point to add the group. Press the + button and start typing the group name. When it appears, set the permission to Read Write. You permission window should have 4 entries at this point. The everyone, the group (likely staff), and the owner (likely the server admin). Then the one you added. The bottom three are POSIX, the final one is an ACE.

4: Now, you need to get your hands dirty and create a custom ACE. Server.app does not allow you to use the Deny rules so break out Terminal.

5: I will assume the Archive folder is in this path /Shares/Archive. First get a list of the folder's ACL using:


ls -le /Shares/Archive


It should like like the following:


drwxr-xr-x+ 2 carbon wheel 68 Feb 18 22:27 Archive

0: user:_spotlight inherited allow list,search,file_inherit,directory_inherit

1: group:archive_users allow list,add_file,search,add_subdirectory,delete_child,readattr,writeattr,readextat tr,writeextattr,readsecurity,file_inherit,directory_inherit


6: Now you must add your deny rule. Use the following command:


chmod +a# 2 "group:archive_users deny delete,file_inherit,directory_inherit" /Shares/Archive


The syntax here is to add (+a) an ACE at index 2 (# 2), an ACE for the group archive_users that states the group can no delete any file or folder and this is inherited all the way down.


7: If you have content in the folder already, be sure to propagate the permissions.

8: Test, test, test.


Remember, the deny rules can have some odd effects. As mentioned, I can think of the renaming and the overwrite as possible deterrents.


A possible alternative is to not give everyone read write access to the Archive. It might be more sane to define two groups. The first groups, Archive_admins, is a subset of users who are entrusted with moving data to archived status. The second group, Archive_users, is the rest of the team and they have read only access, allowing them to pull data but not edit the archive. This allows you to use two simple ACEs in Server.app: Archive_admin = read/write and Archive_users = read.


R-

Apple Consultants Network

Apple Professional Services

Author "Mavericks Server – Foundation Services" :: Exclusively available in Apple's iBooks Store

Feb 19, 2014 4:54 AM in response to Strontium90

OK I sorted this with help from the excellent answer by Strontium90 above.


It still wasn't working with the Deny ACE that was suggested - the Deny ACE wasn't even shown on my sharepoint when doing ls -le /path/to/share!!


However, maybe it is me not understanding inheritance or maybe it's a bug but the deny delete will not apply to the sharepoint itself - IE: It is not until you put a subfolder into the sharepoint that the deny delete applies.


So I created /Archive/ArchiveInHere/


/Archive is the root level of the share


And added the ACE that was suggested above (mine was in position index # 1 though)


And now all is working perfectly. Anything put into /ArchiveInHere by the 'archiveusers' group (or user) cannot be deleted. Many thanks - I hope this helps anyone in the same positon.

Deny Delete in AFP Share - ACL Nightmare :(

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple ID.