That is to say, I read through all the comments in the file vsftpd.conf concerning setting flags for enabling PUT, such as write_enable=YES, anon_upload_enable=YES, anon_mkdir_write_enable=YES

and also:

anon_root=/var/ftp/opendir
cmds_allowed=EPSV,PASV,RETR,QUIT,USER,PASS,QUIT,CWD,PORT,LIST,NLST,STOR,TYPE,PWD,SYST,FEAT
file_open_mode=0777
guest_enable=YES
dirlist_enable=YES
anon_other_write_enable=YES
no_anon_password=YES
log_ftp_protocol=YES
anon_umask=0777

So I assume this is all the settings I need. Or am I missing some setting?

Yes, I know these would be horribly insecure on the open internet, but this IS inside a firewall. But the big question is: why don't these things work? Since I can do a GET, I assume the ports are open where they need to be, but I cannot do a PUT, nor can I create a directory from the FTP client.

Strangely, it does not seem to be using the setting for opendir: the GET is working from the default anonymous user's root.

I had a Wireshark capture file showing what happens, but I can't find it now. If this isn't enough info to debug the problem, I can do another, but for now, is this enough info?

BTW: the FTP server is running on a Fedora 14 machine, the client runs on a machine inside the same LAN. Version# for vsftpd is 2.3.4.

I guess the anon_umask should be 0222

Hi, mejohnsn

I would show you this thread to check your _umask settings
which obviously are not working right for you (hint: 077 -> 022)

You are not the only one to make such a guess, and I -have- seen that setting frequently recommended for similar problems. But when I changed it to 0222, saved the file and restarted vsftpd, the new setting did not solve the problem: I still get "550 Permission denied" (yes, I forgot to say in my original post that that was the message I was getting) when I try to delete a file, and "553 Could not create file" when trying to PUT a file ("ftp -d" shows this is done with the STOR command, which is in my list 'cmds_allowed').

Now just for an additional data point, I went into /var/ftpd/opendir on my FTP server and changed the permissions on the file with "chmod a+w [filename]". I still could not delete it.

Oh, and just in case it is relevant on the directory opendir itself, the permissions are: "drw-r--r-x. 4 root root 4096 Mar 26 10:05 opendir"

One final note: I see in vsftpd.conf, they recommend changing the mask to 022 "if your users expect that". But what DOES this really mean? Does a user running ftp on the command line in Mac OS X 10.6 expect 022?

But when I reread that, I realized you must have meant '022', not '0222'. But the results when using 022 are exactly the same. And I did remember to save the edit and restart the server.

So now what?

so if only root has access to "opendir" then, of course, you will get "permission denied" warnings. You have to make the directory writable for the ftp user group or chown it to the anonymous user, I think.

mejohnsn:

try to make a directory RWX for all users and you will see that permissions are your trouble now.
You have to set permissions on directories, where you want the FTP users to be able to write /delete etc., to that user (and group).
If there are many users accessing the same directory, then make it writable for all of the groups to be able to write to it (code chmod above)

good luck

"Of course"? But anonymous is not a Linux user. Yet that is how the user logs on. And vsftpd is running as root (I start it by logging in as root and then "vsftpd &"). So why wouldn't vsftpd have access? What user's permissions could be relevant if not root's?

The same question goes for lithos, who makes much the same point, but recommends just enabling it for all users. For now at least, I want only anonymous login, so this doesn't sound quite right.

After all: isn't it an insecure thing to do, to make the directory accessible to others? vsftpd is running as root. Or is this itself also a bad idea, perhaps even a bigger security problem? I thought not, since this "standalone mode" is what the vsftpd man page recommends. But please feel free to let me know if this is not longer up to date.

Thanks to both you and lithos for keeping up with this: I may yet try the "chmod -vR 777" to see what that does, though as you no doubt have noticed, I am puzzled which user I should really be doing this for when I have only 'anonymous'.

Hi,

since you want "anonymous" and have write permissions, you actually have no choice but to set the directory / files permissions to 777 (that is to let everybody read/write).

And just for the vsftpd configuration file, I noticed there is missing:
there is actually good example of vsftpd config here
and also here

good luck

If you give 777 permission to the login directory for anonymous user then it will not be able to login and return with error as by default anonymous user cannot login to any directory which has write permission

if you want anonymous user to read and write then let the user create a directory inside the directory where it logs in which should be writable by everyone.
and make the following changes in config file

I think lithos edited his entry which I was unaware of but one thing which I think he missed is anonymous user cannot create any files in the logged in directory with write permission.

It tends to be my weakness I know of, but somehow I'm unable to Solve it :-)

best regards.

??? I followed the instructions at your "actually good example" site, changing the directory to chmod 755, and I get the following error:

ftp 192.168.0.8
Connected to 192.168.0.8.
220 Welcome to internal FTP service. For this LAN only.
Name (192.168.0.8:[name witheld]): anonymous
500 OOPS: vsftpd: refusing to run with writable anonymous root
ftp: Login failed
ftp>

Come to think of it, there was one change I made to the directions in the above: I assumed I could make the directory they refer to as 'upload' the same as my opendir (recall that I set the config var anon_root to /var/ftp/opendir). But when I follow the directions even more literally, making a separate '/var/ftp/upload' directory, I still get an error, only this time I get it upon trying the put command:

230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> put small.cap
local: small.cap remote: small.cap
229 Entering Extended Passive Mode (|||33629|).
553 Could not create file.
ftp>


I also get the same error when I make the following two modifications to the procedure 1) per your other suggestion, chmod 777 instead of 755 2) try to cd into upload from within ftp:


ftp> cd upload
550 Failed to change directory.

BTW: now my directories on the server look like:

dr-xrw-rw-. 4 ftp ftp 4096 Mar 26 10:05 opendir
drwxr-xr-x. 2 root root 4096 Mar 3 2011 pub
drwxrwxrwx. 2 ftp ftp 4096 Mar 28 00:26 upload

Finally, please note that in my very first post I pointed out I already have the following settings:

write_enable=YES, anon_upload_enable=YES, anon_mkdir_write_enable=YES

Isn't it something which I have mentioned in my post??

your "opendir" has wrong permissions (no execute, which blocks any attempt to chdir into it)

should have:
which you set with : chmod 755 opendir
as root user

Hi, lithos-

This would mean that all the time I thought I was logging into /var/ftp/opendir I was really logging into /var/ftp/pub, which possibility I will look into. But how would it explain why I could log in as anonymous, could see the files, but could not change directory into /var/ftp/upload? That is where I got the error, and it DOES have the 'x' permission.

Also, did the CentOS page example you gave earlier work because they left anon_root to the default '/var/ftp/'? It has occurred to me that that is a significant difference between what they did and I did. So when I typed 'cd upload' it was trying to go to 'var/ftp/opendir/upload'? That directory did not exist.

Since the time I wrote the above I verified that even with those permissions, I am able to get into the opendir directory. The pub directory is empty, but I see files when I type 'dir' after logging in as anonymous: they are the same files I see when I ssh to the server and go to /var/ftp/opendir.

This sounds like an SELinux problem.

First, your permissions on your upload directory should be 730, group owned by ftp.

Second, the directory needs to have the correct SELinux file context,

Finally, set the SELinux boolean to allow the ftp daemon to do anonymous write to directories marked as public_content_rw_t

Let me know if this solves your problem.

Mike.