SFTP File Permissions and Ownership: chmod, chown and ACLs
A successful SFTP login identifies the account; file-system permissions determine what it can do. Design those permissions around operations and directories rather than one universal numeric mode.
Start with owner, group and effective identity
A Linux file has an owner, group and mode bits. The server evaluates the account used for the SFTP session, not the person who originally uploaded the file or the account running your local client. Supplementary groups can also affect access.
Inspect the account with id and the target with ls -ld. After group membership changes, start a new session so it receives the updated group list. If the server maps identities through a directory service or shared storage, verify numeric IDs as well as displayed names.
id transferuser
ls -ld /srv/sftp/transferuser/upload
namei -l /srv/sftp/transferuser/uploadDirectory permissions control file operations
Directory execute means traversal, not running the directory as a program. A file mode of 644 cannot compensate for a parent directory that the account cannot enter. Conversely, a writable parent can permit deletion of a file whose contents are not writable.
| Operation | Typical Linux requirement |
|---|---|
| Read a known file | Read access on file; traversal on its parents |
| List directory entries | Read on directory; traversal for useful access to entries |
| Create a new file | Write and execute on destination directory |
| Overwrite existing contents | Write access on file, subject to client workflow |
| Delete or rename | Write and execute on parent; sticky-bit and policy rules may restrict it |
Example: a private upload directory
For one dedicated account, a user-owned upload directory with mode 750 can allow the owner to manage files, the group to inspect them and others no access. Use 700 if the group should have no access. These examples describe the upload child, never the protected chroot root.
Changing ownership requires administrator rights and should target only the intended directory. Record existing ownership before the change. Avoid recursive chmod or chown over application trees because those trees may contain executable files, service-owned data or deliberate exceptions.
sudo chown transferuser:transferuser /srv/sftp/transferuser/upload
sudo chmod 0750 /srv/sftp/transferuser/uploadShared groups and ACLs for collaboration
When an application and an SFTP account share files, plan a shared group rather than giving every local user write access. A setgid directory can make new entries inherit its group, but it does not automatically grant group write permission. Creation modes, umask and ACLs still apply.
Where supported, inspect ACLs with getfacl. Named-user or group entries can grant targeted access; the ACL mask can limit their effective permission. A default ACL influences newly created children and does not retroactively update existing files.
Test a newly created file from each participating account. Check its resulting owner, group and effective access before applying the design to production data. Group collaboration also requires a deliberate decision about who may delete or rename shared entries.
umask affects new files, not existing ones
umask removes requested permission bits when files are created. With conventional requested modes, 027 commonly results in files at 640 and directories at 750. A client can request narrower modes or preserve source permissions, so inspect actual results.
For an internal-sftp account, an administrator can configure -u 027 in the ForceCommand arguments. This is a policy for new creations, not a repair for existing ownership or a way to grant access missing from parent directories. Validate the SSH configuration and test using a separate session.
Windows and final verification
Windows OpenSSH uses Windows accounts and NTFS access control. Review effective permissions, inheritance and explicit deny entries instead of translating Unix numbers directly. Start by displaying icacls output for the destination, then inspect the relevant account in the Security interface.
Validate the exact workflow: list, download, create, overwrite, rename and delete a disposable file. Test both intended access and an operation that should be denied. Keep application and SFTP permissions consistent without making the chroot root writable.
Put the guide into practice.
Review the related Varkuna product or open its detailed user guide.