Hello, When we use scp in sftp mode to copy folder to the machines with the "old" version of ssh, we get the following error: ====== $ scp -vvv -r test/ touser@machine:/home/touser ... debug1: Sending subsystem: sftp ... debug2: subsystem request accepted on channel 0 debug2: Remote version: 3 debug2: Server supports extension "posix-rename@xxxxxxxxxxx" revision 1 debug2: Server supports extension "statvfs@xxxxxxxxxxx" revision 2 debug2: Server supports extension "fstatvfs@xxxxxxxxxxx" revision 2 debug2: Server supports extension "hardlink@xxxxxxxxxxx" revision 1 debug2: Server supports extension "fsync@xxxxxxxxxxx" revision 1 debug2: Server supports extension "lsetstat@xxxxxxxxxxx" revision 1 debug3: Sent message fd 6 T:17 I:1 debug3: Recevied stat reply T:105 I:1 F:0x000f M:40700 debug3: source_sftp: copying local test to remote /home/touser/test debug3: Sent message fd 6 T:16 I:2 Couldn't canonicalize: No such file or directory *Unable to canonicalize path "/home/touser/test"failed to upload directory test to /home/touser/test*debug2: channel 0: read<=0 rfd 4 len 0 debug2: channel 0: read failed debug2: chan_shutdown_read: channel 0: (i0 o0 sock -1 wfd 4 efd 6 [write]) debug2: channel 0: input open -> drain debug2: channel 0: ibuf empty debug2: channel 0: send eof ======== If I understand correctly, the failure is caused by the lack of the " expand-path@xxxxxxxxxxx" extension to sftp protocol in old releases and (lack of) processing it on the server side. For the recent version self-compatibility it was fixed in https://github.com/openssh/openssh-portable/commit/ac7c9ec894ed0825d04ef69c55babb49bab1d32e Is a similar fix feasible to reach better backward compatibility? Many thanks in advance! -- Dmitry Belyavskiy _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev