problems with ftp

[Richard Darling]

One of our customers is trying to ftp files to our L1000 running 11.0 and is having intermittent problems. I have installed the latest patches for ftp. Their machines hang up on them when they attempt the transfer and I receive the following when I check the process:
root:L1000>:ps -ef | grep ftpd
root 22989 570 0 16:43:28 ? 0:00 ftpd: 66.57.243.33: brooks: STOR
cvfcusti^M^J
root 22918 570 0 16:40:04 ? 0:00 ftpd: 66.57.243.33: brooks: STOR
/cvfcusti^M^J

Anyone have any ideas? Thanks.
Richard Darling

[Uday_S_Ankolekar]

Hi,

How big is the file..?? If the file size is bigger than 2 gb then you need set FS to accomodate bigger file.

Check at the receiving end whether file size is increasing while running ftp

Also Can you check by doing "bin" before get/put command

-USA..

[Ron Kinner]

Looks like FTPD is having a problem when it tries to STOR(e) the file named cvfcusti.

Could they be trying to store the file in a directory where they do not have permission?

Where does FTPD store the files by default? Is that directory allowing them to write? Are they doing a CD once they logon? To what directory? What permissions do they have in the new directory. Finally are they trying to give the fullpath for the file when they do a PUT?

Can you ftp into your own machine and try the same thing?

Ron

[Richard Darling]

Uday,
The files are less than 2kb. The files are ASCII.
Ron,
The user is able to ftp some files, but not this one. Therefore, I don't think it is a permissions issue. It appears that the prcoess hangs. They are getting "disconnected by remote host" on my server, but when I grep for ftp I get the output I was showing in the intital post of this thread. It appears that the process is hanging.

I setup my ftpaccess file with:
upload /home/brooks /incoming yes
and

guestgroup ftponly

I put the user in that group and

I then setup a link in the /home/brooks directory:
lrwxrwxrwx 1 root sys 12 Jan 24 10:25 incoming -> /home/ftpd
ir

[Ron Kinner]

Have they tried changing the mode to binary before sending the file? Could be some corruption in the file.

Ron

[Sanjay_6]

Hi Richard,

What you are getting is probably this on the clint side,

Error: 451 Requested action aborted: local error: STOR

The reason could be

//Quote//

Anything that can cause the file system to return an error can potential cause of these type of errors from FTP. For example: 1) Hardware problems causing file system errors. 2) OS problems causing file system errors. 3) The requested files may be locked by another process and therefore are inaccessible. All these types of issues cause the OS to report a problem to ftp server. ftp server then reports these types of failures simply as a "local error" or "server error".

//EndQuote//

Hope this helps.

Regds

[Richard Darling]

Hi Ron,
I'll give that a try in the AM when they get in and post the results tomorrow. However, I know that it is an ASCII file they are creating and the other files are transferring OK.
RD

[Ron Kinner]

It seems to me that if they can get other files to go through that there must be something odd about this one. Is it just this one or does it happen fairly often?

They might also try to gzip the file before sending it. Will definitely need binary mode if they do.

Ron

[Bill Hassell]

Make sure that the user has:

1. Checked the size of the file to be transferred. If it is larger than 2Gb, then the destination must be verified as largefile-capable before trying the transfer.

2. Checked the amount of space available on the destination disk.

As a good practice, never use a simple put or get with one parameter. put and get have 2 parameters, source and destination. Always use full pathnames starting with / as in:

put /etc/profile /tmp/myprofile

Relying on the ftp commands cd and lcd can lead to unexpected transfer locations. Connection can be closed due to permission problems on either end...both ends must allow the transfer. Is the user's machine a PC? Are they using a 'real' ftp at the DOS command line or some Window program? What are the limitations of the Windows program? Ore simply use ftp at the DOS prompt.

[K.Vijayaragavan.]

As you are able to do ftp for other files and you are facing problem in moving this file alone,

You may have to consider these points,

What happens if you try "rcp" to copy the same files?

what happens if you copy the same file to some other folder in the same system?

-Vijay

[Richard Darling]

This morning they were able to ftp the files without a problem from a DOS prompt, which they werent able to do yesterday afternoon. I notice that there are ^M^J at the end of the file name, cvfcusti, in the results (see my first entry on this thread). Could there be extra characters added somehow that are creating a problem, or is this normal?

Sanjay, When the problem occurs they are getting the message that the session was closed by remote host, not the error 451.

Ron, It seems to only be this file and they are sending it from MS boxes so that won;t be using gzip.

Bill,
The files are only 2kb max. There is plenty of space - I setup a separate mount of 100 mb.
They are running the put from a MS box(an NT 4.0 server and an ME PC) using the full path. They are setup as a restricted user so they only put what they see as the root directory. I have a link in their home dir, /incoming, which I use as their target directory. This link is to a separate mount /home/ftpdir.
The command they are running is a simple put. I had set up a local bin dir for them and only put the ls command in there, so that is the only one that they can run.

Vijay,
Based on this data being transferred from a PC or NT boc I don't want to get into any other issues suing rcp. I would rather just use ftp.

Thanks to all... any other ideas?
RD

[Ron Kinner]

Your windows folk can use something like WIN-GZ:

http://download.cnet.com/downloads/0-10097-100-2181397.html

There are several other programs available at www.shareware.com and http://www.winsite.com


^M^J is a carriage return /line feed which the RFC for FTP says has to follow the file name. I'm surprised that your system shows it but I can't say I've ever looked at the ps when doing FTPs.

We had a similar problem with our FTP transfers failing about once a month. The client thought everything was fine but the file was missing the last packet which had the EOF. Turned out to be bad type of NICs. They were sensitive to electromagnetic interference.

landadmin and netstat -s did not show any errors but a long series of pings larger than 1500 bytes would have random failures.

Ron

[Richard Darling]

Hi everyone,
We are still having problems ftp a file from an NT server to our L1000...any other ideas?

I thought I'd bring this back to the top. Thanks.

RD

[Mark Greene_1]

Richard,

are the results the same when you do the ftp from the L server to the NT and get the file? Also, does it change in binary or ascii mode?

Mark

[Richard Darling]

Mark,
They won't let me get the files. I have the same problem with binary or ascii.
RD

[Mark Greene_1]

if they won't let you get, have them ftp to another NT box and look at the files there. If they are having the same issues, it's on their end, not yours (big surprise--NOT, I know).

mark

[Richard Darling]

I'll have them do that. Unfortunately, that doesn't help me get my files.
Thanks.

[Ron Kinner]

Have one of your NT clients run the following ping command:

ping -t -l 5000 a.b.c.d > c:\junk.txt

where a.b.c.d is the address of your server. This ping will continue until they hit ctrl + c. The idea is to look and see if you see any no replies (other than perhaps the first one). Let it run for 5 minutes then ctrl + c it and open junk.txt and search for "request timed out" If you have any then you may have a bad NIC. Run it again with 1400. If no failures at 1400 but failures at 5000 then it's the NIC if you get failures at 1400 too it could be the network.

Ron

[Chris Watson]

Richard,

Did you ever get a solution to this problem, as I am also suffering identical problems.

[Martin Johnson]

Have to checked the file to verify it is not corrupted?

HTH
Marty

[Richard Darling]

Hi Chris,
Yes, I did get the problem resolved, and I apologize to everyone for not posting the solution.

I installed the PHNE_23949 patch and the problem was resolved.

RD