We may earn a referral fee at no additional cost to you when you shop through the links on this page.
You upload a file over FTP and it lands with -rw------- (600) permissions, so your web server, group members, or other users cannot read it. This DevAnswers fix tells vsftpd to create uploads with sensible 644 permissions instead, then explains exactly why the default produces 600.
Quick fix: set local_umask to 022
Check what is set first, vsftpd does not write the directive by default, so an empty result means the 077 default is in force:
grep -i umask /etc/vsftpd.confOpen the file in a text editor such as nano:
sudo nano /etc/vsftpd.confFind the local_umask line (or add it if it is missing), set it to 022, then save and exit:
local_umask=022Save and exit (press CTRL + X, press Y, then press ENTER)
Then restart vsftpd to apply the change:
sudo systemctl restart vsftpdFrom now on, files uploaded by local users are created as 644 (owner read/write, everyone else read). Files uploaded before the change keep their old permissions, the fix only affects new uploads.
On Debian and Ubuntu the config file is /etc/vsftpd.conf; on RHEL-family systems it lives at /etc/vsftpd/vsftpd.conf instead. If a setting seems ignored, confirm you edited the file the running service actually loads with systemctl cat vsftpd.
Why uploads land as 600
vsftpd’s default local_umask is 077. A umask is a mask of permission bits to remove from newly created files. vsftpd starts each upload from a broad read/write base and then strips whatever the umask says, so an 077 umask removes all group and other access, leaving just rw------- (600). This is vsftpd’s own setting, independent of your login shell’s umask, so changing the system umask in .bashrc or /etc/profile does nothing for FTP uploads.
Changing the umask to 022 removes only the write bit for group and other, leaving their read bit intact:
| local_umask | Resulting file perms | Meaning |
|---|---|---|
077 (default) | 600 -rw------- | owner only, the problem |
022 (the fix) | 644 -rw-r--r-- | owner writes, everyone reads |
002 | 664 -rw-rw-r-- | owner + group write |
A umask is subtractive, it lists the bits to take away, so a larger umask means more restrictive files. Stick with 022: it lets your web server and other users read uploads (usually the whole point) while keeping write access to the owner alone. Pushing it to 000 (666) or running chmod 777 makes every upload world-writable, a genuine risk on a shared or internet-facing box.
Files, directories, and anonymous uploads
The same 022 umask gives directories 755. That execute (traverse) bit matters: without it nobody can enter the directory to reach the files inside, so a too-restrictive umask can leave perfectly readable 644 files trapped in a folder no one can open. Two things to watch:
Anonymous uploads use a different setting. If you allow anonymous FTP, local_umask does not apply to them, add anon_umask to the same /etc/vsftpd.conf as well:
anon_umask=022If these are upload-only accounts, you probably also want to deny them interactive SSH access. Existing files are not touched. The umask only affects files created after the change. Fix already-uploaded files in place with chmod:
# files to 644, directories to 755
sudo find /home/billy/ftp -type f -exec chmod 644 {} \;
sudo find /home/billy/ftp -type d -exec chmod 755 {} \;local_umask=000 (which makes uploads world-writable, 666) or by chmod 777. 022 is the correct, secure value for shared-readable uploads. Using SFTP instead of FTP?
If you connect on port 22, you are using SFTP through OpenSSH, not vsftpd, so local_umask has no effect at all. Open the SSH config in your editor:
sudo nano /etc/ssh/sshd_configSet the Subsystem sftp line as below, then save and exit:
Subsystem sftp internal-sftp -u 0022Save and exit (press CTRL + X, press Y, then press ENTER)
Restart SSH (sudo systemctl restart ssh) to apply it. For a chrooted SFTP-only group you can set the same umask per group with a ForceCommand internal-sftp -u 0022 in a Match Group block.
Verify the Fix
Upload a fresh test file as a local user, then check its permissions on the server:
ls -l /home/billy/ftp/testfile.txt-rw-r--r-- 1 billy billy 18 Jun 9 08:40 /home/billy/ftp/testfile.txtThe leading -rw-r--r-- is 644: the fix worked. If you still see -rw-------, work through these:
- You edited the file the service actually loads (check with
systemctl cat vsftpd). - The
local_umaskline is not duplicated or re-set lower down the file, the last matching line wins. - vsftpd really restarted (
systemctl status vsftpdshows a recent start time, not just “active”). - You are testing a new upload, existing files keep their old mode until you
chmodthem. - You are on FTP, not SFTP, those are set in completely different places (see above).