On 14-Apr-2012 10:17 , Jack Tucky wrote:
A user recently started having a problem renaming files using FTP.

They normally log on, change to their "out" directory, download the
files, then issue an REN command to move them to out/history.

They recently started receiving this error and being disconnected
when they try the rename:

ftp> ren 2012041300299857.l45 /history/2012.l45
350 File /giii/out/2012041300299857.l45 accepted. Type new name using
RNTO command.
Connection closed by remote host.

They are able to download the files fine. I checked that they have
authority to all the files and directories and they do.

I've checked WRKREGINF and no exit programs are enrolled. I am trying
to download OpsNav to see if that offers any help.

From the description, I believe that should be instead, the following request [relative path "history" versus path "/history"]?:
ftp> ren 2012041300299857.l45 history/2012.l45

No mention whether "using FTP" as an IBM i FTP client, though presumably using an IBM i FTP server. If also IBM i as client, then perhaps DEBUG 100 to gather a client trace?

Tried yet running with any level [FTP subcommand] DEBUG active before the REName FTP subcommand? Maybe that would show more, even if only the ">>> RNTO /history/2012.l45" [though apparently the desired output is ">>> RNTO /giii/out/history/2012.l45"?], but hopefully also either of "550 Renaming attempt failed." or "250 File renamed as /history/2012.l45" might be seen.

If the client is not IBM i, then when I want to see what happened in the FTP server job, something that is not obvious from DSPJOBLOG of an active joblog, I typically issue a QUOTE RCMD TRCJOB *ON /* with whatever additional parms desirable */. Such a trace could be instead, activated, ended, and spooled from some interactive job instead [and thus no issue for the user having access to both the FTP RCMD feature and the TRCJOB command]; i.e. the TRCJOB *ON issued after STRSRVJOB against the jobnbr/QTCP/QTFTP##### job that services the request, issued from a user with with trace\debug\service capabilities.

Also as far as authority issues, I generally will not spend any time trying to review in advance, the authorities to what might be accessed during the request. For example, if authority to all of the directories in /giii/out/history were verified, but the actual request referenced the directory /history instead, then the attempt to verify that necessary authority were for naught. As such I find that reviewing the T-AF audit entries for the time of the failing activity is much more helpful. Of course that means security auditing has to be in effect before re-creating the failing scenario.

Regards, Chuck

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].