|Dec 7, 2012, 08:35 AM||#1|
File Permissions for multiple users
I'm doing some volunteer IT work for a non-profit trying to gain some experience. For the most part things have gone well, however, someone came to me with a question I haven't been able to solve. we have a 21tb raid set up via thunderbolt to a mac mini server. There's about 10 users who have access to the server who typically work on projects together(video/audio team). The person in charge wanted it set up so all 10 users could write to the same drive, rather than partition it into individual blocks; a Pool type mechanic. I however have run into the problem that if a user creates a new directory permissions on that folder are such that said user has read/write assess, and the group "staff"(everyone in the office) has read only access.
At present I'm able to manually set directory permission for staff to have read/write and if I go to the root directory I can apply it to everyone, however once a new folder is created that process has to be repeated.
I would like so that any new directory is initialized with the permissions of the root folder. Is that possible. If so how/where could I find instructions to do it.
Thanks a bunch!
|Dec 7, 2012, 09:23 AM||#2|
RE: umask and chmod...
...this is the old unix way of doing what you wish...
I believe the bash shell command that you require is "umask". The "umask" command allows you to set the default permissions given to files and directories when users create them, thus if all 10 of your users are in the same group and that group owns the raid volume, then "umask" can be used to specify that all files created by any user of this group will allow all other users of the same group to have Read/Write access.
You can find information on "umask" in the manpage for bash, "man bash", and the manpage for chmod, "man chmod". Be careful, as "umask" typically specifies the permissions that are turned off by default, not the ones that are turned on. It is a mask, in other words, as the name implies.
You can set the "umask" for everyone in a system-wide "/etc/bashrc", "/etc/profile", or "/etc/bash_profile" shell script that is executed when anyone logs into their computer, or you can set "umask" on an individual basis by including the appropriate command in a user's "~/.bashrc", "~/.profile", or "~/.bash_profile" shell script that is executed when the user logs in.
P.S. Since it appears you are using Mac OS X Server (you indicate "mac mini server"), then you can use the File Sharing pane of the Server.app to configure your RAID so that all created files/subdirectories inherit the permissions of the root directory.
Last edited by switon; Dec 7, 2012 at 11:45 AM. Reason: Added P.S.
|Dec 7, 2012, 05:03 PM||#4|
...just a quick comment...I agree with Les Kern...
If you use ACLs instead of umask, then make sure you set the "file_inherit" and the "directory_inherit" permissions on the root directory so that all subdirectories and files will inherit the permissions also. I believe that this is what Les Kern means by full access, it not only includes R/W but also the inherit permissions.
And under most circumstances, it makes more sense to use the ACLs than to use umask.
|Dec 11, 2012, 08:10 AM||#7|
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.
|Dec 11, 2012, 01:32 PM||#8|
RE: ACLs, umask, chown, chmod, chflags, ...
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.
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.
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>".
Last edited by switon; Dec 11, 2012 at 01:47 PM. Reason: Added P.S. (boy, don't I hate spell checking, it always is changing what I type)
|Dec 11, 2012, 10:55 PM||#9|
Thank you for the in depth reply.
Unfortunately< I couldn't get your procedure to help me out.
Meanwhile, a Xerox server tech and programmer happened to drop by as we are installing a newest up to datest IGEN 150.
As first he is an apple geek - I asked him to set it straight for me.
He couldn't get it.
I gave him a printout of your procedure - he couldn't get it to fly either.
I have a new plan for tomorrow.
|Thread Tools||Search this Thread|
All times are GMT -5. The time now is 02:20 AM.