On proftpd/centos I configure the use of virtual user. I can login as a virtual user but I do not have write permission for this users.
The proftpd.conf looks like:
ServerName "ftp01"
DefaultServer on
DefaultRoot ~
AuthPAMConfig proftpd
AuthOrder mod_auth_file.c mod_auth_unix.c
RequireValidShell off
AuthUserFile /etc/proftpd/ftpd.passwd
AuthGroupFile /etc/proftpd/ftpd.group
AuthPAM off
User nobody
Group nobody
MaxInstances 20
UseSendfile off
Here is the content of ftpd.passwd:
user1:hashfrompasswd:50:50::/var/ftp/user1:/bin/false
and ftpd.group:
ftp:x:50:user1
The output of ls -lah
from the home dir (set permission to 755):
# ls -lah
insgesamt 44K
drwxr-xr-x. 10 root ftp 4,0K 27. Dez 11:19 .
drwxr-xr-x. 21 root root 4,0K 8. Jul 2013 ..
drwxr-xr-x. 3 ftp user1 4,0K 7. Jan 15:04 user1
But when I connect to ftp Server as user1 I can connect and login but when I try to put a file or make a directory I get access denied from server. How can I solve this problem?
Your homedir has permissions 755 which mean owner (root in this case) can read,write,execute (rwx) but the group (ftp) can only read,execute (rx).
Either change the owner of the directory to ftp or add group write permissions to the home directory (ie: 775).
EDIT! Cant believe i missed this on first read:
Take a look at your "Ls" dir listing. Notice the . Most likely SELinux. Either temp set to Permissive and test Or better, set a security context:
In your "ls -lah" your user/group ownership is the wrong way around -- But this is not the issue! Your issue is that the dir needs to be writable by the system user that Proftpd is running as. This is not the login virtual user account you have created for FTP login.
In your config you have specified the "daemon" must run as nobody:nobody, by means of the lines User and Group
Adjust the ownership on the directory to nobody:nobody and permissions to read+write for user and group (660). As a last TEMPORARY resort [BAD Naughty form, be VERY CAREFUL!] set dir perms fully permissive (777) - and test your uploads. The dial it back once you know it CAN work, and is owner/permissions issue. This will keep you sane and prevent the throwing of equipment of out of windows.
Ensure you actually have a "nobody" user, and lastly, ensure GID and UID used for virutal users matches this system user.