Yes, as mentioned, changing permissions via the Finder's Get Info box for mounted AFP share points is not an option. The Info box shouldn't even allow you to make the change, in my opinion, but it's there and broken.
And, you'll usually have "custom access" especially if an ACL entry applies to the connected user (you).
But I did notice a couple of questions in this thread that I can answer, so here goes:
*How to make new files and folders write-able by a group instead of just the POSIX owner:* You accomplish this by adding an Access Control List (ACL) entry for the desired group, then give that entry the appropriate read and write permissions. But before you can do that, you need to know three things:
1. ACLs must be enabled on the volume that houses the share point in question. With Leopard Server, that will be the default for any disk with a filesystem that's ACL-capable. However, you can check to see if ACLs are enabled with *sudo fsaclctl -p /Volumes/diskname*. If you need to enable ACLs, do so with *sudo fsaclctl -e -p /Volumes/diskname*, then reboot the server.
2. If your share point already contains files and folders (e.g. it's not empty), then know that simply setting a new ACL entry for read and write with appropriate inheritance will
not magically change the permissions of the existing contents! You'll have to change those permissions manually, which isn't as big of a deal as you might think (read on).
3. Make sure that your POSIX permissions for the AFP share point (and its contents) are set to umask defaults or similar. In particular, you'll need to make sure that the POSIX owner (regardless of the account) has read and write access (and execute/search access if it's a folder). Why? As you'll see later on, any copies made from the server will change their POSIX owners to the user who makes the copy. In some cases, an ACL entry that grants that user (via membership in a group) read/write access will not be preserved on the copy. Such is the case if the copy's original has an inherited ACL entry which grants such access or if the copy's destination resides on a filesystem that does not support ACLs. Then you're back to just POSIX access, and the POSIX owner changes for the copy, but the POSIX permissions are
preserved. Hence, if the POSIX owner of the original had only read access, any copy will grant the new owner only read access as well!
Therefore, before adding the ACL, I recommend the following POSIX permissions:
POSIX owner - doesn't really matter. I recommend root.
POSIX group - again, doesn't really matter; I recommend admin or staff.
POSIX permissions - 0755
You can accomplish this quickly via
chmod and
chown:
sudo chmod -R 755 /Volumes/disk-name/share-point
sudo chown -R root:staff /Volumes/disk-name/share-point
OK, so here are two ways you can add an ACL entry for your group. Let's call the group
designers.
*Via Server Admin's File Sharing section.* Use this to add a new ACL entry for the group
designers by using the plus button. Make sure that you check all Read, Write, and Inheritance commands, and you're set. Note that simply adding this ACL entry in Server Admin will not apply (propagate) it to existing folders and files in the share point. You can
try to use the Propagate Permissions action from the gear menu, but that may not work in every case. (The propagate function of Server Admin has improved, but it's not perfect.) Thus, I only recommend using Server Admin for new (empty) share points.
*Via chmod.* This requires that you use the command line (Terminal), but it's not that bad. You'll have much greater control over what you can do, and you'll be able to alter the permissions of existing files and folders reliably (keep reading - that's coming up).
An example will help; the following command will add an ACL entry that grants all read, write, and inheritance commands for the folder /Volumes/Data-Disk/Collaboration. (Collaboration is the share point's name.)
sudo chmod +a "designers allow readattr,readextattr,readsecurity,list,search,read,execute,\
writeattr,writeextattr,delete,delete
child,add_file,addsubdirectory,write,append,\
file
inherit,directoryinherit" /Volumes/Data-Disk/Collaboration
Again, as with Server Admin, this will apply the ACL to the share point (Collaboration), but not existing contents. Why? Because the
file_inherit and
directory_inherit controls only apply to newly-created or newly-copied files and folders within the share point or within any of its contents that have received such an inheritance or that have the same ACL explicitly defined.
So, how do you take care of existing files and folders? Simply add the
-R (recursive) argument to the above command like this:
sudo chmod -R +a "designers allow readattr,readextattr,readsecurity,list,search,read,execute,\
writeattr,writeextattr,delete,delete
child,add_file,addsubdirectory,write,append,\
file
inherit,directoryinherit" /Volumes/Data-Disk/Collaboration
This will apply the read/write/inheritance ACL to the Collaboration share point
plus any existing files and folders. The only difference is that existing files and folders will receive this ACL entry as an explicitly-defined entry, and newly-created files in the share point (or within its subfolders) will receive the same entry as an inherited one. What's the difference? If files are copied from the server, the ACL entry will be retained only for the files that have the entry set explicitly. Inherited ACL entries will be discarded on the copy in favor of the copy's new parent's ACL entries that are inheritable. This doesn't mean that users will have a read-only copy though: remember that copies preserve POSIX permissions and change the POSIX owner to the action-bearing account (e.g. the user who makes the copy). Hence, my previous recommendation for setting POSIX permissions to root:staff with 0755 access!
*If you have trouble:* If you've previously used Server Admin's File Sharing section to set ACLs, but haven't had any luck, don't give up. ACLs work, I promise! You probably have several "leftover" entries from times when Server Admin didn't finish or when you changed your mind and Server Admin didn't remove the old ACL entry.
The simple solution is to remove any existing ACL entries
before you set your POSIX permissions (and thus, before you set the new ACL for your read-write group). Here's the best way to remove any existing ACL entries:
sudo find /Volumes/Data-Disk/Collaboration -exec chmod -a# 0 {} \;
This command will recursively "walk" through the given folder and its contents (Collaboration) and remove the first (number zero) ACL entry on any file or folder that it finds there.
Important: If it doesn't find an ACL, it will skip over that file/folder, but you'll see a message stating that there's no ACL present. Obviously, if you have a lot of files, you'll see this message repeated
many times. Relax - it's working. After the first run, you've removed the first ACL entry on any files/folders if such was present. Now, run the command again... and again... and again... until you're sure that all previous ACLs are gone. By the end, you'll see lots of "no ACL present" commands. You can check to see if you still have residual ACLs by browsing the share point in Server Admin's File Sharing section. Dig through the folder hierarchy and inspect the permissions of a few items until you're satisfied.
One other problem that you may encounter is that some files may be locked. This may be because users are connected - again, it's best to make these changes with nobody connected, or it may be because the locked flag is actually set. Unlocking files via Get Info is a major pain, especially if you're not the POSIX owner (only the owner and root can change file flags). So, here's another handy command that will unlock everything in the given folder:
sudo find /Volumes/Data-Disk/Collaboration -exec chflags nouchg {} \;
Hope this helps!
--Gerrit
Message was edited by: Gerrit DeWitt
