RE: ACLs, umask, chown, chmod, chflags, ...
I seem to be having the same problem and must not understand exactly you are referring to. How do I set "ACLs" to act properly?
I have several folders I want everyone, who has any business on the server,
to be able to access - change - copy to their own machines - save - or otherwise modify however they want. When I set up the shared folders only the creator an use them. I have set the folders as "Shared". I have set it to "Everyone" can "Read and Write" and said to apply those permissions to all enclosing items. But ... no one, other than the creator, can copy the files to their machines - open the folders - access the files - move the folders within the server or delete any files or folders that they did not create.
Everyone has Administrator privileges. ANd even if Everyone would log in as the Servers "owner" administrator - they can still do nothing to the files on the server.
I would appreciate any guidance through this setup.
I have already wiped re-installed the machine 4 times.
MSD
Wow, four times?! Oh my...
Please don't wipe/reinstall again, I don't think it is necessary.
Firstly, let me assure you that setting the proper permissions on Shared volumes really does work, and allows any user with his/her permissions set properly to have full, R, RW, or custom access to shared files.
Secondly, let me describe in brief general terms what you need. There are two, slightly competing, methods for setting permissions. One is the old unix way known as POSIX, the other is ACLs. A directory/file may have either/or/or both sets of access permissions set. For POSIX, a user has a "umask" assignment that determines what POSIX permissions new files/directories will NOT have, that is, the umask setting is a mask. Let me give you a quick example and follow it with some explanation. Say the umask is 002 for a user. Then when this user creates a file it will have permissions 775. What does this mean? First of all, notice that 002+775=777. Next these three digits are really octal digits to be read in binary, thus 7=111 in binary. A "1" in binary means that the permission is set, a "0" in binary means that the permission is not set. So now for the three octal digits, 777. The first 7 gives the Read, Write, and eXecute permissions (abbreviated rwx) for the user, the middle 7 gives the rex for the user's group, and the last 7 gives the rex permissions for others. Thus 777 means that the file is entirely open for everyone, the user, everyone in the user's group, and for others (everyone): everyone can read this file, can write this file (edit/modify it), and can execute this file (run it if it is a program or search it if it is a directory). A common set of POSIX permissions is 644 which translates to 110-100-100 for the user-group-other rwx access, meaning that the user can read and write, the group can read but not write, and everyone else can read but not write. See, easy isn't it?
Now it turns out that if you want to control every permission and access on every file on your computer, then you will need root privileges first of all to change the permissions on files that you don't own, and the terminal commands "chmod", "chown", and "ls" will become your friends. The "chown" command changes the owner and group of a file/directory. The "chmod" command changes the permissions, both POSIX and ACL, on a file/directory. And the "ls" command shows you what you have accomplished. These commands also have shortcut options, so below I will give you a few example usages. But before doing so, you will have to read up on these commands in the manpages: "man chmod", "man chown", and "man ls". Make sure that you use "ls -ale" to verify that your permission changes have actually worked as you want them to work.
Here goes:
ls -ale <filename>
this command shows the long output, including ACLs, for the file named <filename>.
If you execute this command, you will notice something about the ACLs, and that is the so-called "inherit" permissions. If you give a particular user permission to read and write, but not the inherited right, then the user will not be able to write to subdirectories, etc.
chmod -R ug+rw <directoryname>
this command adds (+) the read (r) and (w) permission for the user (u) and group (g) to the directory <directoryname>, all files in this directory, and all subdirectories and their files all the way to the bottom of the directory tree (-R). Similarly, you can remove the write permission for the group with the command:
chmod -R g-w <directoryname>
where the minus (-) means to subtract the write (w) access for the group (g) for the directory and all of its subdirectories (-R).
If you wish to change the ownership of a file or the file's group, then use:
chown newuser:newgroup <filename>
which will change the file <filename> to have the owner "newuser" and group "newgroup". The -R (recursion) switch operates here too so that you can change the owner and group of a directory, all files in the directory, and all subdirectories and files using the -R switch.
The "chmod" commands also will change the ACLs, such as the inherited rights, of files/directories, but I leave it up to you to read the manpages to figure out how to do this. The above examples should explain what you need to understand the manpages.
Stategy: Okay, now that you understand how to change the permissions/rights for users/groups on files/directories, let's talk about the strategy to use to get your system working. Basically, what I would do is to create a temporary directory ("mkdir Temp") and then add a file to the directory ("cd Temp"; "touch testfile1"; "cd .."). If you do a "ls -ale Temp" you should see the default permissions/rights that are setup on this directory and its file. Then experiment with changing the permissions/rights using the above commands. Then "su username2" where "username2" is another user on your computer (this means to switch your login to the username2 account - of course you need the privilege to do this so you may have to do "sudo su username2" in order to accomplish the switch; a "whoami" command will tell you if you successfully switched accounts). See if username2 has access to the Temp directory and testfile1 file. If not, change the group for username2 to the group for the temporary directory and give this group rwx privileges. Then username2 should have read, write, and execute privileges to the Temp directory and its file. Make sure that you get this working before proceeding. Once you have that working, then "share" this directory and its file, and make certain that username2 has still has access. Once this is accomplished, go back to your original shared volume and do the same thing to it. If you are using the Mac OS X Server to Share your files, then you can get the Server.app to make all of these permission/rights changes for you. I also think you should be able to get the File Sharing pane of the System Preference to make these changes for you too, but I haven't personally done this since I have always used the server software to manage my shares.
Hope this helps.
Good luck,
Switon
P.S. Yes, you can change the permissions on a file so that even you cannot read the file, so be careful. If you get stuck with a file you cannot read or delete or change its permissions, then you will have to use root privileges in order to delete the file: "sudo rm -f <obstinatefile>".
