Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hey Everyone,
I am sure this will be an easy fix for someone. I having a couple of problems with the vsftp:
1: When ever I connect to the server, it accepts my user name and passwd but it takes me to the root dir. I have chroot_list_enable and it does not seem to do anything. I really need it to take me the home direcotry /home/someuser
----------
# You may specify an explicit list of local users to chroot() to their home
# directory. If chroot_local_user is YES, then this list becomes a list of
# users to NOT chroot().
chroot_list_enable=YES
# (default follows)
chroot_list_file=/etc/vsftpd.chroot_list
chroot_local_user=YES
---------
on my vsftpd.chroot_list file i have my user name listed.
2. I get this error when i move into my home directory:
SFTP error: Couldn't get remote handle.
3. Is there a way to have vsftp to accept regular FTP connection? For people who don't use a secure FTP client.
1 - It's acting as it's specified to do. Keep your settings as they are now and try to log in as a user whose name is not in the /etc/vsftpd.chroot_list file, but still has a user account on the machine. That person should be chroot()ed to their home directory or some other designated directory according to your other settings. You may have to adjust the settings that pertain to "local logins", also. As far as I can tell, "local" just means "has an account on the server machine".
2 - I don't believe that vsftpd is an sftp server. This means that its connections are not encrypted over an SSL.
3 - So, people without an SFTP client should be a-ok for logins.
These probably weren't the answers you were expecting, but I hope they help.
Last edited by Tramontane; 01-20-2004 at 10:56 AM.
Cool that worked - much thanks
The problem I am still having is when I remove the user from the system 'userdel someuser' then I would add them again, it still does the same thing. When I try to log in with that same user name vsftp show's the root dir. Is there some log file that needs to deleted?
It may just check the names in the /etc/vsftpd.chroot_list file whenever the daemon starts. You can test that by restarting the vsftpd process(by ending the vsftpd process and restarting it, or through a SIGHUP(i think)) after you edit vsftpd.chroot_list and do your del/adduser stuff. If you use an internet superserver like inetd or its succesor xinetd, this restarting shouldn't be neccesary.
That's still pretty wierd, though. If you have a blank vsftpd.chroot_list, and chroot_list_enable=YES, and chroot_local_user=YES, then all logins should be chroot()ed to their respective home directories.
Basically if chroot_list_enable=YES, it allows you to specify users who can violate the default behavior defined by chroot_local_user.
Last edited by Tramontane; 01-20-2004 at 12:29 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.