Unfortunately I don't have enough reputation to comment because all I wanted to do is stress how important the comment by Richard Fairhurst is and how it should be added to the "official answer". I have seen people here and elsewhere having trouble setting the user home directory or having the user home directory as a "default directory". That's just because ...
Please change /etc/hosts from
or (better) fix the setup to have a proper FQDN and naming scheme.
Any shell you want to use with proftpd should be listed in the /etc/shells file (http://www.proftpd.org/docs/directives/linked/config_ref_RequireValidShell.html)
You should add /bin/false to /etc/shells or set RequireValidShell off in the proftpd config
Note that with the advent of RFC 7151, FTP now has a HOST command for supporting true name-based virtual hosts, just as the Host header does for HTTP 1.1.
And ProFTPD implements this HOST command as of the 1.3.6rc1 release. To use it, you can either simply use DNS names in your <VirtualHost> section, like so:
The problem is, that conntrack_ftp module, which on the fly allows ftp data connections to pass through firewall even if they were to be dropped because of rules, cannot analyze the encrypted stream for PASV/PORT commands. The same applies to not being able to use active mode from behind a firewall/nat with encrypted control connection.
So you need to set ...
Check that SElinux isn't causing you problems
If this fixes your problem then turn SELinux back on (setenforce 1) and then try setting the ftp_home_dir boolean
setsebool -P ftp_home_dir on
which will allow the ftp daemon to access user home directories.
The problem is that %u refers to the local user (which in your case is proftpd). You shoulduse %U (note the capital U), which refers to the FTP user. Note the last paragraph on the ProFTPd SQLUserInfo page, above "See Also".
It's possible and here's my config file:
# Server Configuration: those parameters cannot be elsewhere
ServerName "ftp daemon"
SSH's sftp server has some additional requirements for chroot directories,
ie. user cant have write access to chroot dir in some enviroments this might be a problem.
If You also need ftp/ftps I would suggest giving mod_sftp a go.
We are using it in production on about 20 servers with over 10k accounts with almost nil problems (sftp is the least used ...
If you're experiencing the same issue as I am you will find in your server's auth log that proftpd first tries pam_unix before falling back to the configured authentication method. For me I am using authuserfile and not Unix authentication. As with you my first attempts always fail and the second attempts always succeed.
The proftpd documentation would have ...
Yes, if you install the mod_quotatab extension: ProFTPD module mod_quotatab
. You can set a quota on the number of bytes and the number of files permitted. Set up a cron-job to update the tally once every 24 hours, and voila, you have a daily quota set up, as explained here
Allow 18.104.22.168/24 22.214.171.124/24
in your /etc/proftpd/proftpd.conf.
And the user can log only if it comes from the good IP network.
Or without the IfUser for all users.
It is maybe easier to put a firewall...
There is a bug in ProFTPd v1.3.3 with multi-line output.
This line of output shouldn't be there, or at least shouldn't look like it does:
Reply: 230 Ls oi a:2011-11-06 00:44:45
It is being interpreted as the output for 'SYST', so when the 'FEAT' command it issued, the 'SYST' output is being read, and when 'PWD' is issued, some of the feature response is ...
You will have to give your proftpd virtual users ownership of their files and directories just like you would a real user. You can do this with chown. As the users aren't system users you will have to use the numeric UID:GID e.g. if username is UID 10001 and GID 1111 (from the mysql database) then
chown 10001:1111 /var/www/vhosts/sites/username
chown -R ...
MySQL clients which link against libmysqlclient read global options from the [client] section of /etc/my.cnf. This is a typical behavior for such clients, and ProFTPD is such a client when you use its MySQL module.
The SELinux boolean ftpd_full_access will allow this access, but it also effectively disables SELinux for the entire FTP daemon's operations, so ...
The systemd unit would look something like this:
$ cat /etc/systemd/system/proftpd.service
Description=ProFTPd FTP Server
ExecReload=/bin/kill -HUP $MAINPID
Then you could do:
$ sudo systemctl enable /etc/systemd/system/...
To not be able to "see" the files (assuming that this just means blocking directory listings), the following config might work:
# Block directory listing commands
<Limit LIST NLST MLSD MLST>
Note that this requires that your proftpd be using the mod_ifsession module.
Now, the ...
This is an older thread but I'd just like to add for future readers that we've been configuring servers to use proftpd with mod_sftp for years with no problems at all. I like very much that the separation of services gives fine-grained control over security, the service itself, and user management.
You can configure proftpd to support either or both ...
You might try the following:
DefaultRoot ~ !ftp_special
DefaultChdir /path/to/specialdir ftp_special
The DefaultChdir directive will change the initial/default directory for the logging-in user, just like DefaultRoot, only without the chroot().
Just had this problem with Ubuntu 12.04.2 and ProFTP. I had my FTP user's shell set to /bin/false and ProFTP wouldn't allow that to connect (it showed Error 530).
What I did was followed I uncommented this on my /etc/proftpd/proftpd.conf:
And I also added /bin/false to my /etc/shells file.
Restart ProFTP and you're good!
Hope this ...
To get proftpd to listen only on localhost, you would use both DefaultAddress and SocketBindTight, like so:
By default, proftpd will listen on all interfaces for a given port (e.g. "*:21"). The SocketBindTight directive tells proftpd to bind "tightly" to the address/socket, rather than using a wildcard socket (...
Both MySQL and LDAP work well, pick the one you are already familiar with. :)
If you already have MySQL in use, the one clear advantage of choosing MySQL would be that you could use your existing infra-structure without any new components.
OpenLDAP can be a bit painful to set up, but under extreme load it probably is faster for authentication than MySQL. ...
It looks like you are setting their roots to their respective home directories I would recommend adding a symlink in their home folders that goes to the folder you want them directed to. (if you can just delete their home directories and symlink them as those folders. also you might need to allow access to their home folders. I think but am not sure.
I built a local DNS with dnsmasq and this domain is resolved via another server. It is the reason for slow authenticating. Use IP address instead of domain solved my problem.