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.


8 Answers 8


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:


  • 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, 2017 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, 2017 at 6:24
  • In my case I had local_root pointing to a missing directory - when I modified that variable, error 15 was gone. Apr 29, 2020 at 15:17
  • Omg it worked. I just needed to add allow_writeable_chroot=YES Oct 21, 2021 at 22:11
  • FWIW on version 3.0.3 of vsftpd there is no allow_writeable_chroot option. If your local_root is not writeable by the user running vsftpd then the service will not be able to access the directory and you will get that cryptic GnuTLS error -15. In my case, what I did was change the ownership of local_root to the user running vsftpd
    – mcwayliffe
    Mar 3, 2022 at 19:39

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.

  • 1
    Just ran into the same trap due to a misspelling. Setting a valid local_root directory solved the issue. Dec 20, 2017 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.


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

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.


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.

  • If the answer is that you must allow writeable chroot, how does this help anybody who has this problem? May 2, 2019 at 22:05

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

  • Please note that this particular question has an accepted answer, meaning their problem was already solved.
    – Jeff Schaller
    Aug 28, 2019 at 14:01
  • 1
    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, 2019 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, 2019 at 15:27
  • 1
    Yes, it had the exact same symptons.
    – Rudger
    Dec 18, 2019 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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .