SCP commands fail due to closed connections or no such file or directory.
Client error: Connection to 10.11.12.1 closed by remote host.
Client error: Lost connection.
Client error: scp: /path/file: No such file or directory
Client error: scp: /path/file: Generic file system error
SSHD.LOG might show:
error: authorize_scp_thread(admin) Failed to create path context on cn=user.o=context. rc: 1, errno 0, h_errno: 997, clienterrno: 0
Make sure to have the SSHD materials provided by at least NetWare 6.5 SP6, preferably SP7. These contain several fixes and enhancements to the way paths are handled in SCP sessions.
Before SP6, many of the errors above can be due to the fact that SCP access was only supported to the SSHD server's local SYS volume. This led to many path syntax errors. In SP6, support was added so SSHD, while acting as the server side of an SCP operation, can access any volume of the local server. In SP7, the ability reach a home dir on a remote server was added. (NetWare SFTP server already had these features, but NetWare SCP did not).
[NOTE: Although SSHD.NLM was enhanced to handle this when operating as the server side of an SCP operation, the separate NetWare SCP client (SCP.NLM) was not enhanced. It is still limited to dealing with the local SYS volume, and will assume that any path specified is within the SYS volume. Do not specify a local volume name in an SCP.NLM command on NetWare, because SCP.NLM will treat it as a directory name within SYS.]
Here's the sequence which is now followed for SCP sessions (where NetWare is the "server" end rather than the client end):
First, the user's home server and home volume/directory are determined. This would primarily come from the user's environment settings in eDirectory. If there is no home directory specified in eDirectory, then fall-back defaults will be take from the sshd_config file (within sys:etc\ssh\). Furthermore, the sshd_config file can be set to ignore eDirectory and just use it's own defaults all the time.
Second, the path included in the SCP command is taken into account, and can influence things in various ways:
- If no path is specified (i.e."scp file1.txt user@server:file1.txt" ), the file location is assumed to be within the home server / volume / directory previously determined.
- If a relative path (no beginning slash) is specified (i.e. "scp file1.txt user@server:subdir/file1.txt" ), the file location is determined by appending that path to the home server / volume / directory path previously determined.
- If an absolute path (with beginning slash) is specified (i.e. "scp file1.txt user@server:/vol1/dir1/file1.txt" ), the file location will be the path specified in the command, but located on the *home server*.
Note that the *home server* can be different from the server where SSHD.NLM is actually running. Since the user cannot override the 'home server' in his scp command, then depending upon the combination of settings in sshd_config, it might be impossible for the user to interact with the file system on the server where SSHD.NLM is actually running.