I set up two new CentOS 7 boxes simultaneously, so the configurations should be identical, just different ip addresses and host names.

I installed VSFTPD and configured for passive ports. One box connects fine, no issues, however the second box continuously throws me this error:

GnuTLS error -15: An unexpected TLS packet was received.

Here is the debug FileZilla trace:

Status: Connecting to
Status: Connection established, waiting for welcome message...
Trace:  CFtpControlSocket::OnReceive()
Response:   220 (vsFTPd 3.0.2)
Trace:  CFtpControlSocket::SendNextCommand()
Command:    AUTH TLS
Trace:  CFtpControlSocket::OnReceive()
Response:   234 Proceed with negotiation.
Status: Initializing TLS...
Trace:  CTlsSocket::Handshake()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnSend()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::ContinueHandshake()
Trace:  TLS Handshake successful
Trace:  Protocol: TLS1.2, Key exchange: ECDHE-RSA, Cipher: AES-256-GCM, MAC: AEAD
Status: Verifying certificate...
Status: TLS connection established.
Trace:  CFtpControlSocket::SendNextCommand()
Command:    USER datamover
Trace:  CTlsSocket::OnRead()
Trace:  CFtpControlSocket::OnReceive()
Response:   331 Please specify the password.
Trace:  CFtpControlSocket::SendNextCommand()
Command:    PASS *******
Trace:  CTlsSocket::OnRead()
Trace:  CTlsSocket::Failure(-15)
Error:  GnuTLS error -15: An unexpected TLS packet was received.
Trace:  CRealControlSocket::OnClose(106)
Trace:  CControlSocket::DoClose(64)
Trace:  CFtpControlSocket::ResetOperation(66)
Trace:  CControlSocket::ResetOperation(66)
Error:  Could not connect to server

The error is always right after the password check.

I know the problem IS NOT SELinux, as I disabled that. The problem is also not the firewall, as I tried disabling the Firewall Daemon (firewalld).

Here is the relevant portion of the /etc/vsftpd/vsftpd.conf file.




I did a Google search but did not see any 15 error codes.



I had same error after PASS command in CENTOS 7. (GnuTLS error -15: An unexpected TLS packet was received.)

My solution is following:

I had to add following to vsftpd.conf:


|improve this answer|||||
  • Thank you, for my file /etc/vsftpd.conf i add : user_sub_token=$USER and now not have the GNUTLS error -15 Right now i get another error : The data connection could not be established: ECONNREFUSED - Connection refused by server – inukaze Feb 20 '17 at 6:15
  • 1
    i solved on my file /etc/vsftpd.conf, i put the same value for "listen_address=" & "pasv_address=" i add this last and works i need it :D – inukaze Feb 20 '17 at 6:24

I am posting this answer in hopes that it might help someone in the future, possibly me, as I suffered solving this problem.

I did not have local_root in the /etc/vsftpd/vsftpd.conf file set properly. The setting pointed to a folder, which did not exist.

What through me was that I saw the failure on the password command in FileZilla, so I thought that it did not like the password. What got me thinking in the right direction was that I took the time to research why I was not receiving detailed logs. I received no logs. Once I started receiving debug logs, where I saw the FTP protocols, I saw that the FTP server said OK to the password. Sadly, there was no logging of any kind, but I came across the thought that negotiating the local root would be the next course of action after authenticating the password. I was right and that led me to the problem.

Here is the code fragment in the /etc/vsftpd/vsftpd.conf file, containing the local root.

# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
# (Warning! chroot'ing can be very dangerous. If using chroot, make sure that
# the user does not have write access to the top level directory within the
# chroot)
# (default follows)

Here is how I finally turned on verbose logging, though I will turn that off now to conserve disk space and improve performance.

# Activate logging of uploads/downloads.
# If you want, you can have your log file in standard ftpd xferlog format.
# Note that the default log file location is /var/log/xferlog in this case.
# Activate logging of uploads/downloads.

IMHO, I would consider the comment a bug, as xferlog_enable is more than the actual upload and download of files. This property also turns on logging. A Google research proves that log_ftp_protocol=YES requires xferlog_enable=YES.

|improve this answer|||||
  • Just ran into the same trap due to a misspelling. Setting a valid local_root directory solved the issue. – Johano Fierra Dec 20 '17 at 16:47

I faced exact same error(Error: GnuTLS error -15: An unexpected TLS packet was received.) and banged my head for like an hour but then i figured out that ftp users home directory which was on Gluster volume was not mounted. Mounted Gluster volume and issue resolved.

|improve this answer|||||

You need to allow writeable chroot in your configuration file:

sudo nano /etc/vsftpd.conf

Then add this line at the bottom:


And, restart the service:

sudo service vsftpd restart
|improve this answer|||||

Weirdly for me this issue cropped up when trying to ls after logging in.

It turned out to be that I had uninstalled httpd in favour of nginx and the folder I was using was owned apache:apache and the user got removed when I removed httpd. I chcon'd the directories to nginx:nginx and then replaced the user in these lines in my config file: guest_username=nginx nopriv_user=nginx

Hopefully this helps someone out there because the error messages weren't helpful at all.

|improve this answer|||||

I would like to add to Ndianabasi:

When you have:


and you have chroot enabled, the Chroot directory can't be writable by the user you're trying to log in as. This was my case and the same error came up. I chowned it (the root dir) to root:root and that fixed it for me.

P.S. I checked can't find the mentioned option in the man pages anymore, but it may be available in older versions.

|improve this answer|||||
  • If the answer is that you must allow writeable chroot, how does this help anybody who has this problem? – Scott May 2 '19 at 22:05

check if the directory and its parent directories are readable and executable for the sftp user.

|improve this answer|||||
  • Please note that this particular question has an accepted answer, meaning their problem was already solved. – Jeff Schaller Aug 28 '19 at 14:01
  • thanks, but i just wanted to add how i solved this problem in my case. or do you think its still inappropriate to add something? – Rudger Dec 17 '19 at 15:25
  • I mentioned the existing answer because it sounded like this particular problem had a very specific answer. Did you run across the exact same symptoms? If not, you could always ask & answer your own specific problem with your specific answer. – Jeff Schaller Dec 17 '19 at 15:27
  • Yes, it had the exact same symptons. – Rudger Dec 18 '19 at 15:20

I can't post comments yet so this is partially in response to Scott's comment and to clarify Mr.Fantastic's answer ...

I ran into this same problem and after some trial and error figured out what this actually means and a better solution (IMHO) than setting allow_writeable_chroot=YES.

It means that vsftpd should allow the situation where the user's home directory is writeable by that user. Instead for security reasons I changed the permissions on the user's root folder to 555. According to another thread this mitigates a "ROARING BEAST ATTACK".

In my case the original setup was: (777) drwxrwxrwx /home/ftpuser/

Changing the user's directory to: (555) dr-xr-xr-x /home/ftpuser/

made the user's home directory NOT writeable by the user and thus I didn't have to use the allow_writeable_chroot=YES. This is fine (and more secure) for my situation as I have a preset directory structure and don't want the user making new files or directories in their root folder anyways.

I figured this out when I switched the home directory to /var/ftp via the local_root= parameter for vsftpd and it worked without having to set allow_writeable_chroot=YES. This folder /var/ftp is (755) but owned by root and thus not writeable by ftpuser.

|improve this answer|||||

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.