Here's my situation: I'm setting up an Ubuntu 14.04 web server for a team to share. I'd like the team to have read/write access to everything inside var/www/html (same as CHMOD 775 on every file and folder).

My issue is that SFTP clients on the Mac (Transmit, Cyberduck, and FileZilla) don't respect the default permissions I've set up.

After several hours, I've walked through many steps to accomplish my goal:

Set up team permissions:

  1. Created a myteam group
  2. Added all users to the myteam group
  3. Changed the group ownership of /var/www/html to myteam

At this point, ls -la of /var/www returns

drwxrwsr-x 2 marcelo myteam 4096 Jul 20 13:29 html

Set a default UMASK:

  1. Updated /etc/ssh/sshd_config with Subsystem sftp /usr/lib/openssh/sftp-server -u 002 based on this article.
  2. Updated /etc/pam.d/sshd and /etc/pam.d/login with a new line session optional pam_umask.so umask=0027 based on this question
  3. Updated /etc/pam.d/common-session/ with a new line session optional pam_umask.so and edited /etc/login.defs to change the UMASK line to UMASK 002 based on this question
  4. Rebooted all appropraite services and/or rebooted the entire machine

At this point, if I SSH into the server via a shell, the umask command reports 002, and all new files and folders have the correct permissions. However, if I SFTP into the server via Transmit, Filezilla, Cyberduck, etc. and create files or folders, it does not respect and defaults files to rw-r--r-- and folders to rwxrwsr-x (the folders are correct). I checked, and the FTP clients are not overriding any permissions - those are disabled.

  • /etc/ssh/ssh_config The correct file to update is sshd_config, not ssh_config. Please confirm which file you updated. Beyond that, enable logging in sftp-server (read the sftp-server man page) and check the log to see if clients are explicitly setting file permissions on the files they create.
    – Kenster
    Jul 20, 2015 at 19:20
  • @Kenster - I was editing sshd_config, so it was a typo. SFTP logs are showing open "/var/www/html/untitled file" flags WRITE,CREATE,TRUNCATE mode 0644 when using Transmit, so it looks like the client is setting it? Jul 20, 2015 at 19:56
  • @Kenster - Tried out using plain SCP, and it still uploads with 644 permissions. I'm wondering if it maintains the permissions of the file on my machine when I upload. Jul 20, 2015 at 20:20
  • After some more digging, it looks like files are simply maintaining their source permissions from my local machine. Whether I upload them via an SFTP like Transmit, SCP, rsync, or grunt-sftp, they all keep the local permissions. Not sure where to go with this... Jul 20, 2015 at 21:16

1 Answer 1


This is evergreen problem and it was discussed many times. I wrote short answer here:


Basically you answered yourself using your last comment. SFTP preserves original permissions and truncates umask from it.

  • Thanks - so is the only way around this to use the a less secure FTP system like vsftp and set default permissions through that? It seems like vsftp lets you set up default umask settings, although I haven't tested this yet. Jul 21, 2015 at 13:30
  • I have never tried vsftp, but the problem is not with setting umask, but with the understanding the behaviour of SFTP and umask.
    – Jakuje
    Jul 21, 2015 at 13:54
  • I understand the behavior now after reading through the references in the comments. My question now would be what the best way is to solve my issue? I need multiple users able to upload to a directory where the entire group has read/write privileges. vsftpd seems to have solved it, but I'd still like something more secure and modern like SFTP/SCP. Jul 21, 2015 at 14:08
  • You can also setup VSFTPD to use SSL and gain more security using FTPS, probably even better then using SSH, since you don't have to verify fingerprints and your certificate is signed with some certificate authority, similar or the same as you have for HTTPS.
    – Jakuje
    Jul 21, 2015 at 14:12

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