How to Set SFTP umask in Linux

umask controls which permission bits are removed when a new file or directory is created. For interactive shells, you set it in /etc/profile, .bashrc, or similar files — the umask on Linux guide covers that calculation. SFTP is different: OpenSSH handles uploads with internal-sftp or sftp-server, not your login shell, so a user's .bashrc umask is not a reliable way to control SFTP file modes.

Quick answer

For most SFTP-only accounts, a Match Group block with ForceCommand internal-sftp -u is cleaner than changing the global subsystem line.

How SFTP umask changes permissions

If the SFTP client requests these creation modes, umask 0027 removes the listed bits:

The mode requested by an SFTP client can vary, especially when the client is asked to preserve permissions. The server-side -u setting applies its umask to newly created files and directories, so it can remove permission bits but cannot add missing ones.

The rule that trips up SFTP admins: umask removes permission bits; it does not add missing bits. Umask 0027 does not force new files to 0640. If the client requests 0600, the result remains 0600.

Check the current SFTP subsystem

Before editing sshd_config, see how SFTP is wired today:

sshd -T | grep -i '^subsystem'

Sample output:

subsystem sftp /usr/libexec/openssh/sftp-server

On RHEL and Fedora the binary lives under /usr/libexec/openssh/. On Debian and Ubuntu it is usually /usr/lib/openssh/sftp-server. Add -u through internal-sftp in the subsystem line or in a Match block with ForceCommand.

Set SFTP umask globally

Use a global subsystem line only when every SFTP user should share the same umask. Edit /etc/ssh/sshd_config:

Subsystem sftp internal-sftp -u 0027

That tells OpenSSH to run internal-sftp with umask 0027 for all SFTP sessions. A global change affects every SFTP user on the host, so prefer Match blocks when only some accounts need a custom umask.

Set SFTP umask for a group or user

ForceCommand internal-sftp makes matching accounts SFTP-only; use this form when that is intended. If users still need normal SSH shell access, do not add ForceCommand just to set an SFTP umask.

To give members of sftpusers umask 0027 on SFTP sessions:

Subsystem sftp internal-sftp

Match Group sftpusers
    ForceCommand internal-sftp -u 0027

When one account needs a different umask, use Match User:

Subsystem sftp internal-sftp

Match User deploy
    ForceCommand internal-sftp -u 0022

Only deploy gets umask 0022 on SFTP sessions. Other users keep the default subsystem behavior. If these accounts also need chroot or forwarding restrictions, configure those separately — see restrict SFTP to a directory.

Validate and reload sshd

Always syntax-check sshd_config before reload or restart:

sudo sshd -t

No output and exit status 0 mean the file parsed cleanly. On RHEL, Rocky Linux, and AlmaLinux, reload the running daemon:

sudo systemctl reload sshd

On Ubuntu and Debian the unit is often named ssh instead of sshd:

sudo systemctl reload ssh

Keep an existing SSH session open while testing a reload.

Verify uploaded permissions

Upload a normal test file over SFTP after you set -u 0027:

sftp user@server

At the sftp> prompt:

sftp> put test.txt

On the server, check the mode of the uploaded file:

stat -c '%a %n' /upload/path/test.txt

Note the resulting mode and compare it with the mode requested or preserved by your SFTP client. Replace /upload/path/ with the directory where that user's SFTP session can write.

To show that umask cannot add permission bits, upload two small local files with different source modes and compare the results. With the OpenSSH sftp client used in this test and umask 0027 configured, a 0644 source was created remotely as 0640, while a 0600 source stayed 0600. Your client may request different modes, so check with stat rather than assuming a fixed result.

The important rule is that the server-side umask can remove permission bits, but cannot add bits the client did not request. If uploads stay at mode 600, compare the source mode with the remote file before assuming -u 0027 is ignored.

Troubleshooting

When umask alone is not enough — for example you need forced group ownership or default ACLs on every new file — use setgid directories or setfacl -d rather than expecting umask to add permissions.

References

• sshd_config(5)
• sftp-server(8)

Summary

SFTP upload permissions are controlled in OpenSSH, not in .bashrc. Set umask with internal-sftp -u UMASK inside sshd_config. A global Subsystem sftp internal-sftp -u 0027 line applies one umask to every SFTP user; Match Group or Match User with ForceCommand internal-sftp -u limits the change to selected accounts.

Umask 0027 does not force files to 0640. It removes permission bits from the mode the SFTP client requests. If the client requests 0600, the result remains 0600. Before reloading production sshd, run sshd -t, then confirm remote modes with stat -c '%a %n' file.