hi everyone

i have configured the file vsftp.conf with the directive
anon_root=/d_drive/linux_apps
d_drive has only read access for the normal user..
after starting the server and openig it in browser iam getting error message
-
An FTP protocol error occurred while trying to retrieve the URL: ftp://13.2.2.38/

Squid sent the following FTP command:

PASS <yourpassword>

and then received this reply

OOPS: cannot change directory:/d_drive/linux_apps
-


PLEASE HELP ME TO RUN FTP SERVER

thanks in advance

The user vsftp is running as needs read and write access to that directory. There are options within vsftp to specify the user, and most distros install vsftp with a user named either ftp or vsftp. Find out the user yours runs as, and make sure they have permission to read and write to /d_drive/linux_apps, which doesn't look like it is a good unix directory tree structure, rather looks like somebody is too used to c and d drives like other problem filled OSes.

Peace,
JimBass

I had something similar with VSFTP on FC5 and it turned out to be SELinux. Run 'setup' and set SELinux to permissive while you test. In the first instance that will tell you if that's the problem.

If that is the case, then you'll have to check your system logs for the exact context that is causing the problem. Basically you need to configure your FTP directory to have the FTP context in SELinux. I don't claim to be an expert on SELinux but I made it work with a bit of messing about and brute force!

i have opened the files
in /etc/vsftp
i have the following files
ftpusers user_list vsftpd.conf
----
ftpusers
------
# Users that are not allowed to login via ftp
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody
~
---------------------
user_list
--------------------
# vsftpd userlist
# If userlist_deny=NO, only allow users in this file
# If userlist_deny=YES (default), never allow users in this file, and
# do not even prompt for a password.
# Note that the default vsftpd pam config also checks /etc/vsftpd/ftpusers
# for users that are denied.
root
bin
daemon
adm
lp
sync
shutdown
halt
mail
news
uucp
operator
games
nobody

-------------------------------

vsftp.conf --- trivial file

i have these information ...cannot figure out what u have said abt the ftp user

PLEASE TELL ME IN DETAIL

bye

Please post your entire vsftpd.conf file, and do a "ls -al" on the directory where files are being uploaded/downloaded to/from.

Peace,
JimBass

===============================
vsftpd.conf
===============================
# Example config file /etc/vsftpd/vsftpd.conf
#
# The default compiled in settings are fairly paranoid. This sample file
# loosens things up a bit, to make the ftp daemon more usable.
# Please see vsftpd.conf.5 for all compiled in defaults.
#
# READ THIS: This example file is NOT an exhaustive list of vsftpd options.
# Please read the vsftpd.conf.5 manual page to get a full idea of vsftpd's
# capabilities.
#
# Allow anonymous FTP? (Beware - allowed by default if you comment this out).
anonymous_enable=YES
#
# Uncomment this to allow local users to log in.
local_enable=YES
#
# Uncomment this to enable any form of FTP write command.
write_enable=YES
#
# Default umask for local users is 077. You may wish to change this to 022,
# if your users expect that (022 is used by most other ftpd's)
local_umask=022
#
# anonymous root directory
anon_root=/d_drive/linux_apps
# Uncomment this to allow the anonymous FTP user to upload files. This only
# has an effect if the above global write enable is activated. Also, you will
# obviously need to create a directory writable by the FTP user.
anon_upload_enable=YES
#
# Uncomment this if you want the anonymous FTP user to be able to create
# new directories.
#anon_mkdir_write_enable=YES
#
# Activate directory messages - messages given to remote users when they
# go into a certain directory.
dirmessage_enable=YES
#
# Activate logging of uploads/downloads.
xferlog_enable=YES
#
# Make sure PORT transfer connections originate from port 20 (ftp-data).
connect_from_port_20=YES
#
# If you want, you can arrange for uploaded anonymous files to be owned by
# a different user. Note! Using "root" for uploaded files is not
# recommended!
#chown_uploads=YES
#chown_username=whoever
#
# You may override where the log file goes if you like. The default is shown
# below.
#xferlog_file=/var/log/vsftpd.log
#
# If you want, you can have your log file in standard ftpd xferlog format
xferlog_std_format=YES
#
# You may change the default value for timing out an idle session.
#idle_session_timeout=600
#
# You may change the default value for timing out a data connection.
#data_connection_timeout=120
#
# It is recommended that you define on your system a unique user which the
# ftp server can use as a totally isolated and unprivileged user.
#nopriv_user=ftpsecure
#
# Enable this and the server will recognise asynchronous ABOR requests. Not
# recommended for security (the code is non-trivial). Not enabling it,
# however, may confuse older FTP clients.
#async_abor_enable=YES
#
# By default the server will pretend to allow ASCII mode but in fact ignore
# the request. Turn on the below options to have the server actually do ASCII
# mangling on files when in ASCII mode.
# Beware that on some FTP servers, ASCII support allows a denial of service
# attack (DoS) via the command "SIZE /big/file" in ASCII mode. vsftpd
# predicted this attack and has always been safe, reporting the size of the
# raw file.
# ASCII mangling is a horrible feature of the protocol.
#ascii_upload_enable=YES
#ascii_download_enable=YES
#
# You may fully customise the login banner string:
#ftpd_banner=Welcome to blah FTP service.
#
# You may specify a file of disallowed anonymous e-mail addresses. Apparently
# useful for combatting certain DoS attacks.
#deny_email_enable=YES
# (default follows)
#banned_email_file=/etc/vsftpd/banned_emails
#
# 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
#
# You may activate the "-R" option to the builtin ls. This is disabled by
# default to avoid remote users being able to cause excessive I/O on large
# sites. However, some broken FTP clients such as "ncftp" and "mirror" assume
# the presence of the "-R" option, so there is a strong case for enabling it.
#ls_recurse_enable=YES
#
# When "listen" directive is enabled, vsftpd runs in standalone mode and
# listens on IPv4 sockets. This directive cannot be used in conjunction
# with the listen_ipv6 directive.
listen=YES
#
# This directive enables listening on IPv6 sockets. To listen on IPv4 and IPv6
# sockets, you must run two copies of vsftpd whith two configuration files.
# Make sure, that one of the listen options is commented !!
#listen_ipv6=YES

pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES

==========================================
output for ls -al in anon_rootdir
-rwxr-xr-x 1 root root 95844903 2007-08-08 04:33 1.mp3
drwxr-xr-x 1 root root 43088544 2007-06-10 23:24 Webserver_files
drwxr-xr-x 2 root root 8192 2007-08-10 20:49 UploadsDirectory

please help me to solve this probelm

That setup is a very poor choice, and has problems that obviously will stop it from working.

I would NEVER allow anonymous uploading to an ftp site, particularly one where I have what appears to be a website within the ftp directory! You do realize the way you have this partially setup, that you are giving everyone in the world write access to the Webserver_files directory as well?

Fortunately, *nix security has stopped you from doing something crazy like this. Look at the ownership of the anon_rootdir directory -

So everything in that directory is owned by root, and the only user with write permissions again is root. That is why your ftps failed, because any user you log in as doesn't have root level access, as they shouldn't.

To fix this, I would make some changes. First off, I wouldn't allow anonymous access. If that is actually a website in Webserver_files, then the only person who should be writing in that directory is/are the person/people who own and run the website.

Since you have local_enabled set to yes, then I'd create a new user, and as a home directory, give them /d_drive/linux_apps. Then you need to chown /d_drive/linux_apps to be owned by this new user. Another option that is even more secure and probably better is to use the chroot options in vsftpd.conf, and chroot the user into their home directory, either /d_drive/linux_apps or the easier /home/newuser. Then configure apache to show the website from their directory, and all will fall into place.

Peace,
JimBass

the webserver files that i have shared is not the actual webserver files...it is sample webserver files downloaded from net... i need to share it for my friend..

i want that directory to be read by others..
that directory has read permissions for the normal user that i have login...
how to set a user & password for the ftp server with read permissions to that directory for the user who logs in into this server..

Please help me to do this

THANKS IN ADVANCE
bye

Any user that exists on the machine can read those files. Any user who logs in through ftp should also be able to download then read those files.

You need to create a user for ftp, so it makes sense to make the user name ftp as well. The spot they should have direct access to is the ftp location, so we'll make that their home directory. Also, we'll have to chown some already existing files. I'm also going to only allow uploading to the uploads directory. If you want to allow people to write to Webserver_files, then do your own homework and figure out how.

This also assumes FC7 has the adduser program, and that it is identical to the Debian one. If it doesn't, then you're on your own. They probably have some GUI way to create users.

Then we change ownership of that directory to some better values -

The restart vsftpd, just to be safe.

That should do it, but it still is not a good way of doing this.

Peace,
JimBass

It should work, and even anonymous people can still upload to the upload di