ThisCalculator

Everyday

Fix FTP Error 553 Could Not Create File on CentOS

Updated · Standard formula, shown below

Fix FTP Error 553 Could Not Create File on CentOS

FTP error 553 “Could not create file” on CentOS means the FTP server cannot write the uploaded file to the target directory. This usually happens due to incorrect directory permissions, SELinux blocking, or a misconfigured FTP server (like vsftpd). This guide walks you through the most common fixes, from checking permissions to adjusting SELinux booleans, so you can upload files successfully.

What You’ll Need

  • Root or sudo access to the CentOS server
  • Command-line access via SSH
  • Knowledge of the FTP user account and the directory where uploads fail

Step-by-Step

  1. Identify the FTP user and target directory. Determine which user you are logging in as and the absolute path of the directory where the upload fails. For example, if you log in as john and upload to /var/www/html/uploads, note that path.
  2. Check directory permissions. Run ls -ld /path/to/directory to see the owner and permissions. The FTP user must have write (w) permission on the directory. If not, change the owner or permissions. For example, to give the user john ownership: sudo chown john:john /path/to/directory. Or to allow group write: sudo chmod 775 /path/to/directory (adjust group as needed).
  3. Test with a simple upload. Try uploading a small file again. If it works, you’re done. If not, proceed.
  4. Check SELinux context. On CentOS, SELinux often blocks FTP writes even if permissions are correct. Run ls -Z /path/to/directory to see the SELinux context. For a typical web directory, it should be httpd_sys_content_t or public_content_t. If it’s default_t or something else, you may need to adjust it.
  5. Enable the FTP write SELinux boolean. The most common fix is to enable the ftpd_full_access boolean. Run: sudo setsebool -P ftpd_full_access 1. This allows FTP daemons to write to any directory. If you prefer a more restrictive approach, enable ftpd_anon_write for anonymous uploads, but for regular users, ftpd_full_access is often needed.
  6. Restore SELinux context if needed. If the directory has the wrong context, you can restore the default for that path. For example, for /var/www/html: sudo restorecon -Rv /var/www/html. This sets the correct context based on the directory’s purpose.
  7. Check vsftpd configuration. If you use vsftpd, ensure it allows writes. Open /etc/vsftpd/vsftpd.conf and verify these lines exist and are not commented out: write_enable=YES and local_enable=YES. Also, ensure anon_upload_enable=NO if you don’t want anonymous uploads. After changes, restart vsftpd: sudo systemctl restart vsftpd.
  8. Check disk space and inodes. A full disk or exhausted inodes can cause write failures. Run df -h to check disk space and df -i for inodes. If either is 100%, free up space or delete files.
  9. Verify the FTP user’s shell and home. Ensure the FTP user has a valid shell (like /bin/bash) and that the home directory exists and is accessible. You can check with grep john /etc/passwd.
  10. Test with a different FTP client. Sometimes the client sends a command that the server rejects. Try using a different client (e.g., lftp or curl) to isolate the issue.

Common Mistakes

  • Ignoring SELinux. Many CentOS admins forget that SELinux is enforcing by default. Even with 777 permissions, SELinux can block writes. Always check SELinux booleans and contexts.
  • Setting permissions too broadly. Using chmod 777 is a security risk. Instead, use the principle of least privilege, like 775 or 770 with proper group ownership.
  • Not restarting vsftpd after config changes. Changes to vsftpd.conf require a restart to take effect. Without restarting, the old settings remain active.
  • Forgetting to check the directory path. The FTP user might be chrooted to their home directory. If the target directory is outside that, they cannot write there. Check the chroot_local_user setting in vsftpd.conf.

Tips

  • Use getsebool -a | grep ftpd to see all FTP-related SELinux booleans and their current state.
  • For a more secure setup, instead of ftpd_full_access, you can set the correct SELinux context on your upload directory. For example, if it’s under /var/www/html, use sudo semanage fcontext -a -t httpd_sys_rw_content_t '/var/www/html/uploads(/.*)?' followed by sudo restorecon -Rv /var/www/html/uploads. This allows read/write only for that directory.
  • If you are using passive mode FTP, ensure the firewall allows the passive port range. Check /etc/vsftpd/vsftpd.conf for pasv_min_port and pasv_max_port, and open those ports in firewalld.

Troubleshooting

If the error persists after following the steps, try these additional checks:

  • Check vsftpd logs. Look at /var/log/secure or /var/log/messages for FTP-related errors. For example, sudo tail -f /var/log/secure while attempting an upload can show SELinux denials.
  • Temporarily disable SELinux to test. Run sudo setenforce 0 to set SELinux to permissive mode. If the upload works, SELinux is definitely the cause. Re-enable with sudo setenforce 1 and then adjust booleans/contexts properly.
  • Check for file system issues. Run sudo fsck -f /dev/sdX (replace with your partition) if you suspect corruption, but only if you can unmount the partition first.
  • Verify the FTP server is not in read-only mode. Some FTP servers can be configured to allow only downloads. Double-check your server configuration for any read-only directives.

Frequently Asked Questions

Why does FTP error 553 happen even with 777 permissions?

On CentOS, SELinux can block writes even if Unix permissions allow them. The SELinux context of the directory must permit FTP writes, and the appropriate boolean (like ftpd_full_access) must be enabled.

How do I permanently enable the ftpd_full_access boolean?

Use the -P flag: sudo setsebool -P ftpd_full_access 1. This makes the change persistent across reboots.

Can I fix this without giving full SELinux access?

Yes, you can set a specific SELinux context on your upload directory, such as httpd_sys_rw_content_t, and then use restorecon to apply it. This allows write access only to that directory.

Does this affect both anonymous and local users?

Yes, the error can affect any user. For anonymous users, you also need to enable anon_upload_enable=YES in vsftpd.conf and set the appropriate permissions on the anonymous upload directory. SELinux booleans like ftpd_anon_write may also be needed.

What if I’m using a different FTP server like ProFTPD?

The steps are similar: check directory permissions, SELinux contexts, and server configuration. For ProFTPD, the config file is usually /etc/proftpd/proftpd.conf, and you may need to set AllowOverwrite on for existing files.

How do I check if SELinux is the cause quickly?

Run sudo setenforce 0 to temporarily disable SELinux, then try the upload. If it succeeds, SELinux is the culprit. Re-enable with sudo setenforce 1 and then adjust the booleans or contexts.

Related

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.