550 permission denied vsftpd
 

Hi, I'm having trouble configuring my vsftpd version 2.2.2 on Centos 6.6. I successfully log in, but I cannot make any changes (creating files, directories, whatever):
ftp> mkdir t
550 Permission denied.
ftp>

This is how my vsftp.conf looks:
All users are mapped to the ftp user. /mnt/storage/ftp is owned by ftp and there are no permission problems (the mount point is /mnt/storage). I use pam for authentication, which seems to be working fine from what I can tell from the logs and the fact that I can log in, of course.

/mnt/storage is a linux partition and it's mounted like this:
/dev/sdb5 /mnt/storage ext4 defaults 0 0

Which is really unimportant, because I tried to use the root partition also, and I get the same problem.

On some site someone suggested allow_writeable_chroot=YES, but this directive is not identified by vsftpd.

I kind of ran out of ideas. Any suggestions?

You are not able to create any directory and you get permission denied. So it is good to assume that you are not able to upload anything on your ftp server as well. Right?

What output do you get when you logged into FTP server and try to run ls command?

Also share the output of uname -a.

Selinux may be the issue here.

Enable ftp home directories

Restart vsftpd

Also check /etc/pam/ I installed vsftp the other day and even though my config files and permissions were set correctly a PAM file for vsftp was blocking me from writing anything.

T

I forgot to say that SELinux is disabled, so that's not the case.

Yes, I cannot upload anything. I tried it with filezilla.

this is the output of ls:
"see" is an empty directory that I've created.

@thegwer
What do I need to check exactly in /etc/pam? You're too ambiguous for me.
If it's important, this is how my /etc/pam.d/virtual-ftp file looks like:

What are directory permissions?
Are they writable to user ftp?

@vincix

I was in a hurry and didn't feel like messing with it, I ended up moving the file virtual-ftp out of /et/pam.d and then restarted vsftpd and it worked fine. I have not since had the time to play anymore with the PAM authentication.

If I move it somewhere else, I cannot log in anymore, as one would expect. The file is essential for login credentials through pam. I make use of pam, as you can see from my vsftpd.conf.

Do you recommend any other authentication modes for vsftpd that I can use, then? And if so, can you instruct me?

There is one test you can try just to narrow down the issue. Is it possible for you to set 777 on ftp directory which is owned by ftp. Once done try to upload to FTP by logging in via command line or filezilla and try to upload. If it works then it is file permission issue.

If even after setting 777 it doesn't work then it has something to do with authentication which is indeed not propagating the file system permission to user mapped to ftp user or ftp user itself.

Another simple test would be login as normal user on the system, switch to ftp user using su - ftp and then try to browse using simple cd command: cd /mnt/storage/ftp just to be double sure about filesystem permissions.

The ftp user has /sbin/nologin set in /etc/passwd. That's how it was set up by default and, from what I've read, this is how it should be. So I'm really not sure if this is a real test. However, just for the sake of it, I did change the line to /bin/bash so that I could log in directly and had no permission problems - I could create directories, etc., but when logging in to ftp, I get the same 550 permission error.

I did change the permission to 777, but the problem remains.

I'm quite stuck, and I don't understand, 'cause it should be a little more straightfoward, given that I'm only trying to set up a rather basic configuration of vsftpd, just to make it work and later to add maybe some other more advanced configurations.

@zafar. You can see from the post previous to yours what the folder permissions are. So the answer is yes, it's 755 (which is consistent with the vsftpd.conf directive local_umask=022)

Alright let us give this a try, make a backup of your exiting vsftpd.conf file. Make the following changes:

1. Append the following to vsftpd.conf file:

2. Restart vsftpd service

Check and see if you are able to upload.

If it does not work, then modify the following line in vsftpd.conf file:

1. pam_service_name=virtual-ftp to pam_service_name=ftp

2. Restart vsftpd and then give it a try.

If that also doesn't work then it will be a good idea to revert to orginal config and then take a packet trace to see if there is anything in there.

This is interesting. After inserting the directive you suggested, I get another different error when I try to create a folder:

So the error description is different this time (the previous one was: 550 Permission denied.). So it must have triggered something.

Changing the pam_service_name directive to ftp makes me unable to log in anymore, 'cause the file is /etc/pam.d/virtual-ftp - I know you know that, but I suppose you wanted to verify if pam doesn't append a prefix or anything.

What should I do next exactly? What would you suggest exactly for traffic analyzing?

Before we go ahead with packet trace the last thing you could is to make sure that /mnt/storage/ftp which is owned by ftp:ftp is set to 775 or 770 doesn't matter, the only thing we are interested in is that both group and user have read, write and execute access. The reason I am saying so because it might be possible that though ftp user has got full access but group permission is pulling him down. Most restrictive permissions prevail.

Edit: Incase if the above mentioned plan doesn't work then you can run tcpdump -i <ethX> -w /tmp/packet_trace.pcap. Once packet capture is started on FTP then you can try accessing FTP server to generate that error which will be captured in the trace. Then we can have a look at the trace what server is responding with when requesting to create directory. To stop packet capture just hit ctrl+c on the terminal.

Ok, I am slightly (or more) stupid. Before I inserted the virtual_use_local_privs=YES directive, I created the empty directory called "t" with the ftp user that I logged in with (after changing the default shell in /etc/passwd), then I logged in and tried to create AGAIN the directory "t", having forgotten that I had already created it. So the reason why the error description was different was not a matter of permission, but of a duplicate.

So now it works just fine.

Thank you for your help, the directive made all the difference.

You're welcome. Thanks for marking the thread as solved!

Enjoy Linux!!!