With the way I have my sftp server set up, I have some directories that I give accounts access to by placing a bind mount within the sftp root directory. The problem is that the sftp server gives an error when trying to move (via rename) files across the bind mounts. For example, say that in my sftp root directory there are two subdirectories: Files1 and Files2 where Files2 is a bind mount to another area within the file system. (In my case, the bind mount directories are all within the same partition as the sftp root) When I try to move (again via rename) /Files1/a to /Files2/b (or vice-versa) I get an error. If I try to do the same thing where there are no bind mount directories involved, with the same uid/gid ownership and permissions, it works just fine. The error is very generic and doesn't really give any clue as to what is causing the problem. Please let me know if I can provide any more information, especially if you have trouble reproducing the bug. This is on a Gentoo system.
I realize that the sftp server was throwing an error because it can't rename across mount points. (Even though the bind mount in this case is sourced from the same partition, I assume there is no way for the server to know that) I'm using bind mounts to give different accounts, each with their own chroot, access to directories that need to be shared between specific accounts, but not with all accounts. So I want to append to this report a request for adding a copy command to the sftp server. I realize this is not part of the "official spec" but spec doesn't do me a bit of good when it prevents me from getting anything done. Make it an optional extension if you must. This will allow to move over mount points using copy + delete origional. -scp / ssh : will not work for me. I'm using a chroot sftp session that is locked down. I really don't like the idea of remote users in my scenario to be running commands not provided by the internal sftp server or anything that requires a shell. This is mainly for obvious security reasons since we are creating accounts for external clients our business deals with. -moving via copy-local : My users are dealing with huge media files. This is not a good idea.
OR (Don't know why I didn't think of this earlier) just rework the rename function to detect when the user is trying to rename across a mount point and have it do a copy + delete original internally in those instances.
I think it might be worthwhile to do a vendor extension to allow local copies on the server side, e.g. "cp@openssh.com" or somesuch. We could reuse this to implement fallback to copy either on the server or the client side.
There is an old IETF Draft which proposed several SFTP extensions, including a 'copy-file' extension: http://tools.ietf.org/html/draft-ietf-secsh-filexfer-extensions-00 This extension is supported by the SmartFTP client and by the proftpd mod_sftp module. Thus perhaps using 'copy-file', rather than a vendor-specific extension, might be a slightly more generic approach.
I like the idea of a draft standard that has already been implemented elsewhere. Might want to check an make sure the other implementations didn't deviate from the draft, or you could have an interoperability mess on your hands.
i've filed bug 2948 and posted patches for implementing the "copy-data" sftp extension. it's a little lower level than "copy-file", but it's pretty trivial to implement a "cp" client command with open+copy+close ops. so maybe that's good enough ?
sftp got a cp command via the copy-data extension in OpenSSH 9.0
Closing bugs from openssh-9.1 release cycle