First, find where you run you NcFTPd. Usually this is the line in the /etc/inittab. Edit the command line so that you use a “-v” flag when you launch it. For example, you might change it so it read “/etc/ncftpd/ncftpd –v /etc/ncftpd/general.cf /etc/ncftpd/domain.cf”.
Next, restart NcFTPd. Verbose logging is now enabled, and this information is sent to the NcFTPd “misc” logs. If you forgot where the “misc” logs are at, look in the general.cf for the log-misc option.
Now that you've enabled verbose logging, here's how you can use it to diagnose a problem.
By default, NcFTPd doesn’t log anything except critical errors to the NcFTPd “misc” logs (as specified in the general.cf for the log-misc option). There are also “xfer” and “session” logs, but those are intended for accounting rather than problem-solving. By enabling verbose mode, you can see the exactly how client programs are communicating with NcFTPd since you see each line of communication between client and server.
For example, this sample shows why a user’s uploads were failing:
2000-02-07 04:23:20 #u2 | New connection from 192.168.7.49 to 192.168.7.50. 2000-02-07 04:23:20 #u2 | Using default virtual host eth0 (192.168.1.20, www.example.com). 2000-02-07 04:23:20 #u2 | >> 220 www.example.com NcFTPd Server (free personal license) ready. 2000-02-07 04:23:20 #u2 | << USER joeuser 2000-02-07 04:23:20 #u2 | >> 331 User joeuser okay, need password. 2000-02-07 04:23:20 #u2 | User "joeuser" found in /etc/passwd (uid=359). 2000-02-07 04:23:20 #u2 | << PASS ******** 2000-02-07 04:23:20 #u2 | >> 230-You are user #2 of 3 simultaneous users allowed. 2000-02-07 04:23:20 #u2 | >> 230- 2000-02-07 04:23:20 #u2 | >> 230 Logged in. 2000-02-07 04:23:20 #u2 | << CWD public_html 2000-02-07 04:23:20 #u2 | >> 550 No such directory. 2000-02-07 04:23:20 #u2 | << MKD public_html 2000-02-07 04:23:20 #u2 | >> 257 "/home/joeuser/public_html" directory created. 2000-02-07 04:23:20 #u2 | << CWD public_html 2000-02-07 04:23:20 #u2 | >> 250 "/home/joeuser/public_html" is new cwd. 2000-02-07 04:23:20 #u2 | << TYPE A 2000-02-07 04:23:20 #u2 | >> 200 Type okay. 2000-02-07 04:23:20 #u2 | << PORT 192,168,7,49,8,88 2000-02-07 04:23:20 #u2 | >> 200 PORT command successful. 2000-02-07 04:23:20 #u2 | << LIST 2000-02-07 04:23:20 #u2 | >> 150 Opening ASCII mode data connection for /bin/ls. 2000-02-07 04:23:20 #u2 | ls 000 /home/joeuser/public_html all 2000-02-07 04:23:20 #u2 | Data connection closed. 2000-02-07 04:23:20 #u2 | >> 226 Listing completed. 2000-02-07 04:23:20 #u2 | << MKD _private 2000-02-07 04:23:20 #u2 | >> 550 Could not make directories: No space left on device 2000-02-07 04:23:20 #u2 | << MKD images 2000-02-07 04:23:20 #u2 | >> 550 Could not make directories: No space left on device 2000-02-07 04:23:21 #u2 | << TYPE I 2000-02-07 04:23:21 #u2 | >> 200 Type okay. 2000-02-07 04:23:21 #u2 | << PORT 192,168,7,49,8,89 2000-02-07 04:23:21 #u2 | >> 200 PORT command successful. 2000-02-07 04:23:21 #u2 | << STOR index.htm 2000-02-07 04:23:21 #u2 | >> 150 Opening BINARY mode data connection. 2000-02-07 04:23:21 #u2 | >> 450 Write error: No space left on device 2000-02-07 04:23:21 #u2 | Data connection closed. 2000-02-07 04:23:21 #u2 | Connection closed.
Unfortunately, like many of today’s client programs, this particular
program failed to recognize the numerous errors that had occurred and proclaimed
success.
First, put NcFTPd into verbose mode and then try a login, using the regular “ftp” client on the same machine as the server processes. Often the problem has nothing to do with the login process. Some, but not all, common problems include:
If you think the problem is that NcFTPd isn’t validating the user’s password correctly, you can try using the “tspwd” diagnostic utility, which is in the “extra” directory of the NcFTPd package. As superuser, run it as “./tspwd –l the-user-name”, then try to validate the password. The utility dumps lots of debugging output which is helpful for locating the problem; send the output of the utility to tech support if you suspect a problem with NcFTPd rather than this particular user.
This example shows how an administrator used “tspwd” to determine why “joeuser” could not login:
bash# ./tspwd -l joeuser SpwdLibraryInit ------------------------------------------------------------------------------- This test is used to verify that: (a) The encrypted passwords can be accessed; and (b) Passwords can be authenticated. crypt = [pYw5pQf1/i11w] encrypted guess == encrypted answer DES crypt works. GetSpwdName name=joeuser wantC=1 wantSupp=1 wantClose=1 InitSpwdStruct PwdToSpwd pw->u=joeuser wantC=1 wantSupp=1 DES crypt password detected. DES crypt password not long enough. PwdToSpwd: pw->pw = [x] len=1 getspnam PwdToSpwd: Getspnam's spwptr->sp_pwdp was [*], alg=0 PwdToSpwd: Pp->username = [joeuser] PwdToSpwd: Pp->passwd = [*], alg = 0 PwdToSpwd: Pp->uid = 6 GetUserGroups maxg=32 u=joeuser PwdToSpwd: Pp->gid #0 = 0 PwdToSpwd: Pp->homedir = [/sbin] PwdToSpwd: Pp->shell = [/sbin/joeuser] Endspent endspent GetSpwdByName rc=0 Password for joeuser: crypt = [**kKHnP/IhsG.] encrypted guess did not equal encrypted answer Password was NOT authenticated. This is not surprising since it appears that the encrypted password was not looked up correctly.
The answer is that the encrypted password that NcFTPd read was “*” which means that the entry in the shadow password file was invalid. (Also note that the regular /etc/passwd file entry had it’s entry for the encrypted password field as an “x”, so NcFTPd then consulted the shadow password file.)
The “*” notation in the shadow or passwd file is often used to denote that the user’s account is disabled, since the old DES crypt algorithm could never produce an encrypted password containing a “*” character. The administrator fixed this problem by setting the password for joeuser manually, i.e., as root, “passwd joeuser”.
The "INCOMPLETE" keyword means the data transfer connection is lost are aborted forcefully by the user before the user received all of the data. If you see a lot of these, that could mean that there is heavy packet loss or just low throughput, which is causing the users to get frustrated and cancel the download. It could also indicate a problem with networking hardware in between the server machine and the client machine involving dropped/misrouted/corrupted packets.
You will also get “permission
denied” for many other
errors. For example, you can't
overwrite an existing file in /incoming,
filenames must also not contain any illegal characters, etc.
If you really want to know the exact
reason, you may be able to find out by putting NcFTPd into verbose
mode, repeating the steps you did to produce the problem, and then checking
the log output of the session in the NcFTPd “misc” logs.
The reason for pre-loading users and groups for printing the user and group names in “ls” output. That’s it. If you don’t care about that (and it really doesn’t matter much in the days where GUI client programs don’t show it anyway), you can disable that by setting both a-ls-names and u-ls-names to “no” in the general.cf (and restart NcFTPd).
The reason it is taking so long for you is that your site is apparently using NIS (or perhaps LDAP), and it takes time to read each user record from your NIS server.
NcFTPd
does not run from inetd.
Period.
It does support TCP Wrappers,
however. It just reads the same
files that “tcpd”
does. Install NcFTPd like
you normally would (i.e. not in inetd.conf)
and see the documentation for the tcp-wrappers
option.
There is a feature which sleeps a few seconds between batches of FTP command primitives to prevent people from trying to DoS the server. You can tune it, however, by changing the value of the throttle. If you're experiencing the throttle, most likely you're working over a fast network and/or doing large numbers of small transfers. External users are most likely not going to be throttled.
The purpose of the entry in the /etc/inittab is to automatically re-run NcFTPd in case it exits. For example, the standard procedure for restarting NcFTPd is to kill the processes and let "init" respawn a new batch.
The problem is that your inittab entry is repeatedly exiting/respawning, which means that NcFTPd is failing to start up and is immediately exiting. Typically that means you already had an instance of NcFTPd running when you added the inittab entry, or there's a fatal error being logged by NcFTPd.
First, disable your inittab entry by editing /etc/inittab and commenting out the line that runs NcFTPd. You do that by prefixing the line with a # character, followed by running "init q" to tell "init" to reload the inittab.
Next use "ps" to list all the processes running on the system (usually "ps -ef" or "ps aux"). If you see any "ncftpd" processes running, that was the problem. Kill those processes and re-enable the inittab entry (uncomment, and "init q" which will start up NcFTPd again) and you're finished.
Otherwise, from a shell prompt, run NcFTPd manually using the same command line you're using in the inittab, except remove any occurances of "-q" and make sure you add a "-v" if necessary. For example, your command line at the shell prompt might be something like "/usr/local/etc/ncftpd/ncftpd -v /usr/local/etc/ncftpd/general.cf /usr/local/etc/ncftpd/domain.cf". Since the problem wasn't that NcFTPd had already been running, you should see an error logged to the screen (and also the "misc" logs). Fix the problem and then re-enable your inittab entry.
The FTP client program is using
flags to “ls” that NcFTPd doesn’t understand or support.
Most often this is because you’re using NcFTP client version prior to
version 3, such as version 2.4.3. You can fix this by
upgrading to NcFTP (client) version 3.0.
It almost always means that you
forcefully terminated NcFTPd the time before, using “kill –9”.
Always do a proper shutdown of NcFTPd (i.e. use
“kill –15”
instead) so that NcFTPd can clean up after itself before it exits.
One side effect of a
forceful shutdown is that NcFTPd’s shared memory pool persists.
This error message means that NcFTPd removed the old shared memory
pool and created a new one, but other than that, it is harmless.
Usually this means
that the system is not configured to support a large enough shared memory pool,
and usually this problem comes up when you’re running Solaris.
The problem is that the system by default places a limit on the maximum
size of a shared memory pool, and in this case, this maximum is set too
conservatively. When your max-users
is around 306, on Solaris that causes the size of the shared-memory pool to
exceed 1 megabyte, which is the default limit for Solaris.
To fix this problem
on Solaris, you need to tune your system by changing (or adding, if not present)
a setting to your
/etc/system file. Add
"set shmsys:shminfo_shmmax=10485760" to
/etc/system and reboot the system.
This will cause Solaris to use 10 megabytes as it's limit instead of 1
megabyte, and will increase the limit of users to about 3000.
Note that NcFTPd itself has no such user limitation, it is only
limited by the operating system.
You need to run it as “ncftpd /etc/ncftpd/general.cf /etc/ncftpd/domain.cf” rather than “ncftpd /etc/ncftpd/domain.cf /etc/ncftpd/general.cf”. In other words, you’ve reversed the order of the parameters on the command line.
NcFTPd dumps errors to stderr until the logging process is started up, and at that point, all other errors are logged to the “misc” logs as specified in the general.cf. When you startup NcFTPd you may want to redirect stderr into a file, such as “ncftpd … 2> startup.errors”. If that file is empty after it exits, then you need to look in the misc logs. Also, until you've solved this problem, when you start it up only use the "-v" flag and not "-q" nor "-q -v".
There is already a process that is waiting for FTP connections. Most likely that is /etc/inetd, and you can fix that by commenting out the ftp service line in /etc/inetd.conf and restarting /etc/inetd. It could also mean that there is another instance of NcFTPd running already. Kill that one off first.
That means no process is currently listening for the connection; make sure NcFTPd is running.
Be sure NcFTPd isn't erring out when it starts up and is prematurely exiting. To do that, from a shell prompt, run NcFTPd manually using the same command line you're using in the inittab, except remove any occurances of "-q" and make sure you add a "-v" if necessary. For example, your command line at the shell prompt might be something like "/usr/local/etc/ncftpd/ncftpd -v /usr/local/etc/ncftpd/general.cf /usr/local/etc/ncftpd/domain.cf". If you see see an error logged to the screen (and also the "misc" logs), fix the problem then start NcFTPd (if you're using the /etc/inittab, all you should need to do is "init q" to start it up).
Yes, but for home directories on an NFS mount, the FTP server machine needs to have root privileges translate accordingly on the NFS server. The reason is that NcFTPd runs as root, but often the default for NFS mounts is to translate “root” to “nobody” when accessing the NFS mounted directory. That causes NcFTPd to fail because it tries to access the user’s home directory while running as “root”, and the privileges have been mapped to “nobody” which does not have permission to access the home directory.
If you really want to allow FTP over an NFS mounted filesystem (which is bad news for performance anyway), you can change the NFS server so that the “root” user on the FTP server is trusted for the home directory export on the NFS server (i.e. not changed to “nobody” when the FTP server machine accesses the share).
Usually that involves changing the “exports” file and adding the appropriate option. Try the manual pages for “exports”, “dfstab”, “share”, “nfsd”, etc to see how to do that, since the exact process varies per platform.
