Creating FTP User who doesn't get 403 on created folders/files - Ubuntu

Question

I've got an Ubuntu 14.04 server running apache2

If I SSH in, I can create a directory and files in /var/www/html and they are served appropriately.

If I FTP in with a user I setup (whose 'home' I set to /var/www/html)- I cannot create directories or upload files. If I make that FTP user the owner of the HTML directory - I can then create directories and upload files, but they do not get served. Instead I get a 403 error saying it's forbidden.

So, I'm pretty sure it's a rights issue but I don't want to have to do everything through SSH in order to create directories and pages. I made root owner of the /var/www/html again just to avoid any issues.

So - what is the best process for creating an FTP user (for example named FTPUser) that has the rights to create directories and upload files via FTP? I have created that user - but I'm newer to Ubuntu and unfamiliar with 'best practice', this is a server that will be facing outward to the world so I can access it while not at home as well - so I don't want to just give full access away easily.

I will be the only one accessing this server - so really I just need one user who can access via FTP and create/delete/edit things in /var/www/html

Answer 1

The 403 is likely because of the permissions of the files when created by FTP upload; likely they are not readable by "other", and are owned by a group that the webserver process isn't a member of.

There are several ways to fix this, the simplest of which would be to make the FTP user's primary group "www-data". Then any files uploaded as that user should be readable by the webserver.

Alternatively, you may find the FTP server has a "umask" configured, preventing the "other" bits being set, and changing that to something like 022 will mean uploaded files will retain the potential r-x bits for "other".

A secondary issue is the security of FTP in general (i.e. plain text passwords); might I suggest you try and use SFTP instead, with ssh-keys, which is much more secure. The group/permissions issues will likely remain the same, and require the same solution(s)