VSFTPD cap_set_proc and dead but subsys locked errors and solution

last updated in Categories Linux, Troubleshooting

VSFTPD is the one of the easiest and secure FTP server out there. However today it bumps back with two errors.

#1: 500 OOPS: cap_set_proc error

After successful user login vsftpd will display an error:
$ ftp ftpserver.xyz.com


Connected to ftpserver.xyz.com.
220 (vsFTPd 2.0.5)
Name (localhost:vivek): vivek
331 Please specify the password.
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
500 OOPS: cap_set_proc
ftp: bind: Address already in use

cap_set_proc is POSIX capability manipulation on processes function (related to filesystems but I am not sure). After searching bit I found the solution. You need to load the standard Linux capabilities security module:
# modprobe capability

#2: vsftpd dead but subsys locked error

This is another error – one of my clients was receiving while starting vsftpd. There was already ftp server running and address 21 was bind to this ftp server. So vsftpd dead but subsys locked error was generated. xinetd was configured to run wu-ftpd (quite old ftp software). Solution was simple I had removed the wu-ftpd.

Posted by: Vivek Gite

The author is the creator of nixCraft and a seasoned sysadmin, DevOps engineer, and a trainer for the Linux operating system/Unix shell scripting. Get the latest tutorials on SysAdmin, Linux/Unix and open source topics via RSS/XML feed or weekly email newsletter.

9 comment

  1. Great troubleshooting tip, it will come handy some day.

    Do you know how to limit user to their home directories? What I want is user should not able to visit /root or /tmp directory or all other directory.


  2. If we are getting this error “vsftpd dead but subsys locked ” then
    then follow the followid steps: –

    netstat -tupnla |grep “:21”
    output like
    tcp 0 0* LISTEN 3876/xinetd
    kill -9 3876
    then restart ftp service
    /etc/init.d/vsftpd restart and
    service xinetd restart

    It will solve your problem.

    1. That’s a temporal solution.

      IF you encounter the “vsftpd dead but subsys locked” then it’s most likely a second ftp daemon that is started in /etc/xinetd.d

      Try this:
      cd /etc/xinetd.d
      grep -i ftp *

      => IF there is some sort of ftp service listed (gssftp, wuftp, etc) remove it from your xinetd.d folder (eg. if it is gssftp: rm gssftp) and then, to prove that everything is fine, restart your system (shutdown -r now) or at least restart xinetd AND vsftpd
      service xinetd restart
      service vsftpd restart

      IF your configuration is fine it will no longer cause any problems!

      Most other solutions (stopping xinetd, starting ftp service, starting xinetd) is NOT solving the problem, it’s just messing up the other ftp service that should not be running at all. AND: After the next reboot it will fail again -> So the problem is not fixed.
      Removing the second ftp-service WILL fix the problem!

  3. I am facing problem in vsftp server. I’m working on RHEL4 server. the vsftpd service was working fine but now suddenly I found
    that it is not working. Whenever I restart or stop the service I’m getting following messages.
    1. Service vsftpd status
    Vsftpd dead but subsys locked
    2. Service vsftpd stop
    Shutting Down vsftpd: [Failed]
    3. Service vsftpd start
    Starting vsftpd for vsftpd: [ok]
    4.Service vsftpd status
    Vsftpd dead but subsys locked

    Kindly suggest….what can be done so that the vsftpd service work properly


    Have a question? Post it on our forum!