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.
ftp>
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
midrange.com
