Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a linux server I want to use to share files between users in my company. Users will access the machine with sftp or secure shell.

Here is what I have:

cd /home
ls -l
drwxrwsr-x  5 userA         staff      4096 Jul 22 15:00 shared
(other listings omitted)

I want all users in the staff group to be able to create, modify, delete any file and/or directory in the shared folder. I don't want anyone else to have access to the folder at all.

I have:

  1. Added the users to the staff group by modifying /etc/group and running grpconv to update /etc/gshadow

  2. Run chown -R userA.staff /home/shared

  3. Run chmod -R 2775 /home/shared

Now, users in the staff group can create new files but they aren't allowed to open the existing files in the directory for edit. I suspect this is due to the primary group id associated with each user which is still set to be the group created when the user was created. So, the PGID of user 'userA' is 'userA'.

I'd rather not change the primary group of the users to 'staff' if I can help it but if it is the easiest option, I would consider it.

And, a variation on a theme, I'd like to do this same thing with another directory but also allow the apache user to read files in the directory and serve them.

What's the best way to set this up?

share|improve this question
add comment

3 Answers

up vote 4 down vote accepted

What you have actually looks correct. You have the setgid bit set on the directory, so new files created should inherit the staff group. They do still remain owned by the creator, though. I suspect the problem is that the umask for your users is defaulting to 022 or even 077, which means new files they create will not have the group-write permission by default. The user/group ownership is correct, but the group permissions do not permit other members of the group to write (or maybe even read) the files.

Pick a user in the staff group and set the umask to 002 or 007, which means new files will be owner- and group-writable. I suspect this will correct the problem:

bash$ umask
0022
bash$ umask 002
bash$ umask
0002

Also, you noted you don't want anyone outside of the staff group to have any access to the directory at all. You should modify the directory permissions to 2770 to achieve this, otherwise non-staff will be able to read (but not modify) files in the directory.

For the last question about the apache user, the easiest way is probably to add that user to the staff group.

share|improve this answer
    
Correct. vim was complaining about the file but when I force write to an opened file, it did it. It did change the owner of the file which is okay. –  JR Lawhorne Jul 23 '09 at 20:53
add comment

I agree with his findings. About the FUSE filesystem Daemon. I have rewritten the procedure on how to get this local share between users to be done easily on http://airkayu.com/node/24 just in case you are still in a maze.

share|improve this answer
add comment

The problem is the sftp deamon doesn't take the login scripts and comes up with a umask not allowing write to group.

To get around this, create a script that sets the umask and then runs the sftp server: cat /usr/lib/openssh/sftp-server-prot umask 02 exec /usr/lib/openssh/sftp-server

Then edit ssh/sshd_config to use the above wrapper script: Subsystem sftp /usr/lib/openssh/sftp-server-prot

Then restart the sshd.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.