[SOLVED] SSHFS: Moving files inside a mounted directory

Risse · 2022-03-09 05:28:10

I am mounting my server root directory with SSHFS on my local machine on /mnt/server.

My server has two disks in it, 1st one is SSD mounted on /, and 2nd one is HDD mounted on /mnt/hdd.

I can read, modify and delete files in both server's / and /mnt/hdd okay. Even moving files inside the same physical disk is fine, but when moving a file from one disk to another (let's say, "mv /mnt/server/somefile /mnt/server/mnt/hdd/somefile"), I get the error "Operation permitted".

I have checked all the permissions, uid etc and everything should be okay. Of course when I SSH into the server, I can move the file using "mv" no problem.

These are my settings for the mount in /etc/fstab in my personal machine

user@remoteserver.lan:/                /mnt/server             fuse.sshfs      delay_connect,_netdev,user,idmap=user,transform_symlinks,identityfile=/home/me/.ssh/id_rsa,allow_other,default_permissions,workaround=rename,uid=1000,gid=1000 0 0

And this is what fstab looks like in the server

UUID=SSD-UUID-HERE /               ext4    errors=remount-ro 0       1
/dev/disk/by-uuid/HDD-UUID-HERE /mnt/hdd auto nosuid,nodev,nofail,x-gvfs-show 0 0

Last edited by Risse (2022-03-09 11:23:35)

Maniaxx · 2022-03-09 07:53:21

The 'mv' command just handles filesystem metadata not the data itself. It cannot copy data. So the behavior is correct.

Last edited by Maniaxx (2022-03-09 08:01:44)

-thc · 2022-03-09 09:12:49

This seems to be a limitation of SFTP/OpenSSH:

SFTP doesn't have a command to move files, only a rename command. In OpenSSH (the de facto standard implementation), this is implemented with the rename system call, which moves a file inside a filesystem. There is no command that can move a file to an arbitrary location, nor is there a command to copy a remote file to another remote location.

mpan · 2022-03-09 09:23:32

mv can copy files. If the source and the destination are on two different file systems, it copies the data to a new file at destination and then removes the file at source. It is even pretty vocal about doing that.

I believe this is a case of the user being confused by the abstraction: it’s sshd on remote side that refuses to perform the operation. If I understand correctly, what Risse is experiencing, the situation looks like this. mv locally invokes a rename call. The call is handled by SSHFS, which passes it to the remote sshd as either SSH_FXP_RENAME or SSH_FXP_EXTENDED/posix-rename@openssh.com. At this point it’s already beyond mv: it sees a single file system, that file system swallows the request. Whatever may still save the situation is sshd. But that is not happening. At least not in OpenSSH. As you can see in the source, both process_extended_posix_rename (sftp-server.c:1370 in 8.9p1) and process_rename (sftp-server.c:1254) use the rename(2) call, which renames a file. But that call of course can’t succeed, because the source and the destination are on two different file systems. There is also no attempt to make copies, which is not unexpected, as it’s not easy to implement in such a context.

In other words: the situation arises from the file system abstraction not being conveyed in a manner you are being used to. Not even a bug, just mismatch between expectations and reality. SSHFS does its best to make a remote system feel like a local one, but there are some inherent limitations it can’t deal with.

Last edited by mpan (2022-03-09 09:27:57)

Risse · 2022-03-09 11:22:59

mpan wrote:

mv can copy files. If the source and the destination are on two different file systems, it copies the data to a new file at destination and then removes the file at source. It is even pretty vocal about doing that.
I believe this is a case of the user being confused by the abstraction: it’s sshd on remote side that refuses to perform the operation. If I understand correctly, what Risse is experiencing, the situation looks like this. mv locally invokes a rename call. The call is handled by SSHFS, which passes it to the remote sshd as either SSH_FXP_RENAME or SSH_FXP_EXTENDED/posix-rename@openssh.com. At this point it’s already beyond mv: it sees a single file system, that file system swallows the request. Whatever may still save the situation is sshd. But that is not happening. At least not in OpenSSH. As you can see in the source, both process_extended_posix_rename (sftp-server.c:1370 in 8.9p1) and process_rename (sftp-server.c:1254) use the rename(2) call, which renames a file. But that call of course can’t succeed, because the source and the destination are on two different file systems. There is also no attempt to make copies, which is not unexpected, as it’s not easy to implement in such a context.
In other words: the situation arises from the file system abstraction not being conveyed in a manner you are being used to. Not even a bug, just mismatch between expectations and reality. SSHFS does its best to make a remote system feel like a local one, but there are some inherent limitations it can’t deal with.

Thank you, this was really helpful.

And thanks all for responding, I will mark this thread as Solved.

Arch Linux

#1 2022-03-09 05:28:10

[SOLVED] SSHFS: Moving files inside a mounted directory

#2 2022-03-09 07:53:21

Re: [SOLVED] SSHFS: Moving files inside a mounted directory

#3 2022-03-09 09:12:49

Re: [SOLVED] SSHFS: Moving files inside a mounted directory

#4 2022-03-09 09:23:32

Re: [SOLVED] SSHFS: Moving files inside a mounted directory

#5 2022-03-09 11:22:59

Re: [SOLVED] SSHFS: Moving files inside a mounted directory

Board footer