The setup is we have a VPS running Debian Squeeze, and I've set up a shared directory for us to share files. So far I've followed this guide:


I've also set the umask to 002 correctly (see the comments on that guide), so we can both now create files and directories directly on the server and we both have read/write permissions on them.

The only problem is that a lot of our files are created on our local machines (both running Ubuntu 10.10), and then dumped on the server. This results in only the creator of the file/directory having write permissions on, and the other member of the group I set up for sharing this folder only having read access.

My next thought would be to change the default umask on our local machines, but it seems a bit extreme to have to do that, and I don't know if it's a security risk.

Can someone tell me if there's a better solution to what I'm trying to achieve, or if this really is the way to go?

Many thanks in advance

  • How are the files dumped onto the server ? If using ftp which ftpd is running on the server ? – user591 Mar 16 '11 at 8:53
  • I'm using SFTP graphically through Nautilus on my Ubuntu desktop. I assume that means the fact that I can transfer files to it using SFTP that the server is running this also, but I don't have too much experience with this, so if you mean something else then let me know. Cheers. – Jagot Mar 16 '11 at 11:33
  • @Jagot: can you run ps aux | grep ftp on your server and tell us which ftp daemon is running - it's likely vsftpd|proftpd. – user591 Mar 16 '11 at 11:53
  • @Iain: Here's the result of that command: '~$ ps aux | grep ftp tom 3484 0.0 0.1 3300 748 pts/0 S+ 13:10 0:00 grep ftp' – Jagot Mar 16 '11 at 13:13
  • 1
    @Iain: I don't think there is an ftp server running - I haven't set one up - I'm just doing everything through ssh. Is there any other way I can find out what's going on? – Jagot Mar 16 '11 at 14:28

I'd use a different approach and share the files through an access control list on the directory.

First make sure access control lists are enabled on the filesystem where the directory resides (make sure that the corresponding entry in /etc/fstab contains acl in the fourth column). Also make sure you have the acl utilities installed (on Debian, install the acl package). Then give both users an inheritable write permission on the directory.

setfacl -m user:other_user:rwx /path/to/directory
setfacl -d -m user:other_user:rwx /path/to/directory

If there are more than two users, either repeat this command for each user (the ACL is implicit for the user who created the directory); or put the users in a group (as you already did), and use -m group:group_name:rwx in the setfacl command.

  • sorry it has taken me so long to reply to this as I have only just been able to implement this, but I'm still in the same situation of the files I dump in this directory that I have created on my local machine only have read/write permissions for me, and only read for the rest of the group. I don't know if this is as a result of all the messing around I've done in this particular directory. Still the only way I can get it to work is by setting the umask on my local machine 0002. Files I create on the server itself are fine, but that's not the method we mainly use. – Jagot Apr 24 '11 at 12:56
  • @Jagot: I think we need more information to help you then. Please edit your question to describe precisely how you upload files to the server, and show the output of getfacl on a file that doesn't have the desired permissions and the containing directories all the way up to the root of the shared space. – Gilles 'SO- stop being evil' Apr 24 '11 at 14:41

Sorry I was being thick in the comments. the sftp-server is being run by root and you pick up root's umask. You should be able to fix this by editing your /etc/ssh/sshd_config file and changing the line

Subsystem sftp /usr/lib/openssh/sftp-server


Subsystem sftp /bin/sh -c `umask 0002; /usr/libexec/openssh/sftp-server`
  • watch out for the smart-quotes in this answer! (did you copy-paste from this blog jeff.robbins.ws/articles/… ? It seems to derive from this site's very own @Gilles :)) – simon Mar 17 '11 at 2:59
  • @simon: I think it came from the Ubuntu forums but it's been stuck in my tiddlywiki for a few months. – user591 Mar 17 '11 at 7:11
  • @simon: That was a different Gilles. I'd have recommended ACLs anyway. – Gilles 'SO- stop being evil' Mar 17 '11 at 20:48

In addition to Iain's answer, which should work (but watch out for the smart-quotes, and see below for a caveat), at the top of /etc/init.d/ssh you will find:

# Provides:     sshd
# Required-Start:   $remote_fs $syslog
# Required-Stop:    $remote_fs $syslog
# Default-Start:    2 3 4 5
# Default-Stop:     
# Short-Description:    OpenBSD Secure Shell server


umask 022

and you can change the value here.


many S/FTP clients will try to set the permissions on newly uploaded files to match the permissions on the local system, so check if this is what's happening. If it is, you can usually disable this option in the settings of the client you're using to upload.


as another suggestion, when creating a set-up like this, I always make full use of the sticky-bit for group ownership (i.e., I set all directory permissions to 2775) so that newly created files and directories inherit the correct group ownership.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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