Open /etc/selinux/config
Change selinux=enforcing or permissive to disabled.
Remember to restart the server!
Of course, you also need to determine the following questions:
1. Is the user restricted from logging in by vsftpd? For example, the username is in /etc/ftpusers and is blocked from logging in.
2. Is the pam authentication option turned on in vsftpd.conf (I often make mistakes when I compile and install it by myself) (See if there is pam_service_name=ftp or vsftpd in vsftpd.conf. Which one it is depends on
Who is under the service file /etc/pam.d of the PAM module? Mine is ftp and its configuration is as follows:
#%PAM-1.0
auth required /lib/security/pam_listfile.so item=user sense=deny file=/etc/ftpusers onerr=succeed
auth required /lib/security/pam_unix.so shadow nullok
auth required /lib/security/pam_shells.so
account required /lib/security/pam_unix.so
session required /lib/security/pam_unix.so
If some users in /etc/ftpusers will be denied
3. Are the permissions of the relevant folders correct?
Regarding the issue of "some local users cannot log in to vsftpd, but some can",
None of the existing local accounts in the system can log in. The configuration of my /etc/vsftpd/vsftpd.conf file is as follows:
local_enable=YES
write_enable=YES
chroot_local_user=YES
pam_service_name=vsftpd
/etc/pam.d/vsftpd exists and is normal.
The error message when logging in is the same:
500 OOPS: cannot change directory:/home/xxxx
Login failed.
421 Service not available, remote server has closed connection
Their home directories are all /home/xxxx. The permissions of /home and /home/xxxx are both 755.
None of the above accounts can be logged in through ftp. These are commonly used and can be logged in using shell.
I created a new usr1 account
# useradd -G test -d /tmp/usr1 usr1
Can log in via ftp, and his home is /tmp/usr1, which is on the / partition. I mounted /home to /dev/hda9.
#mount
/dev/hdb1 on/type ext3 (rw)
/dev/hda9 on /home type ext2 (rw)
So, I guess: Is it because of the /home partition that "accounts whose home directory is in the /home partition" cannot log in?
In order to verify the above assumption, I tried to create another account
useradd -G test -d /home/usr3 usr3
The permissions of /home and /home/usr3 are all 755.
usr3 ftp login failed.
500 OOPS: cannot change directory:/home/usr3
Login failed.
421 Service not available, remote server has closed connection
At this point, I think it is certain that it is due to the /home partition that the "account whose home directory is in the /home partition" cannot log in.
Reference article:
I finished my second upgrade to Fedora Core 4. Not everything is ironed out yet with the build of course. But one thing is for sure a lot has happened to the RedHat I knew before.
I must say of all the changes, for me the nicest addition is the new SELinux extensions. For deep background on the reasons for and theory of SELinux read, The Inevitability of Failure: The Flawed Assumption of Security in Modern Computing Environments
The more I work with SELinux the more I realize I need to know about it, and how exactly it does all its stuff. It certainly changes things relating to users, directories and access. As I am starting to learn it, I'm sure I'm doing things the hard-way. :)
The major difference, so far for me, in Red Hat's SELinux is the way ftp is handled. vsftpd is still the server which is great. However, it seems to be designed to run as a daemon rather than invoked via xinet.d. If you grab a working copy of the xinet.d file for vsftpd you can invoke it via xinet.d wrapper. I did my first server upgrade in this manner. The current one I am trying as a daemon. I certainly think I will miss some of the features that the xinet.d wrapper brings, and may yet return to it.
Of all the issues I saw most notable is if you want to enable chroot directory's outside of the normal /home/xxx vsftpd. These will fail with a
500 OOPS: cannot change directory: /mnt/xxxxx
I was able to use ftp if I logged in with an account with a directory in /home, but once I set a user account to have a home drive outside of /home (in this case on a mounted secondary disk) vsftpd barfs the above .
I found information at the NSA that indicates you can disable SELinux protection of the ftp daemon.
setsebool -P ftpd_disable_trans 1
This seems a bit drastic. It certainly works for now though.
I think ultimately the issue resides with policies, but as SELinux policies are new to me, it will take time before it all gets sorted out. As I spend time with the new SELinux extensions in Fedora Core 4 I will keep you updated on my thoughts and configuration lessons.
Solution:
# setsebool ftpd_disable_trans 1
# service vsftpd restart
I use FC4 and tried the method in your previous post, and it was solved immediately. Therefore, it can be determined that the cause lies in SELinux.