Bug 1656826 - mv does not work on sshfs volumes (Numerical result out of range)
Summary: mv does not work on sshfs volumes (Numerical result out of range)
Alias: None
Product: Fedora
Classification: Fedora
Component: fuse-sshfs
Version: 29
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Peter Lemenkov
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-12-06 12:11 UTC by Jean-Luc Richier
Modified: 2019-02-12 02:55 UTC (History)
8 users (show)

Fixed In Version: fuse-sshfs-3.5.1-1.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-02-12 02:55:49 UTC
Type: Bug

Attachments (Terms of Use)

Description Jean-Luc Richier 2018-12-06 12:11:36 UTC
Description of problem:
Since coreutils-8.30, the mv command is incompatible with sshfs <=3.4.0):
The rename call has been modified, and sshfs code report an invalid return code which triggers the message "Numerical result out of range"

Version-Release number of selected component (if applicable):
fuse-sshfs 3.4.0

How reproducible:

Steps to Reproduce:
1. mount a sshfs volume: sshfs fileserver: ~/mnt
2. touch ~/mnt/yyy
3. mv ~/mnt/yyy  ~/WWW/mnt/xxx

Actual results:
mv: cannot move '/home/user/mnt/yyy' to '/home/user/mnt/xxx': Numerical result out of range

Expected results:
mv done

Additional info:
This bug has been corrected in release 3.5.0 on https://github.com/libfuse/sshfs
So please upgrade the version

Comment 1 Matt 2019-01-02 21:00:10 UTC
Same problem here 3 different F29 machines, await the update, thanks!

Comment 2 Danilo de Paula 2019-01-02 22:27:48 UTC
+1 with this problem.

Comment 3 Csaba Henk 2019-01-24 16:00:51 UTC

Recently mv(1) got to the habit of attempting renameat2() syscall with flags. It's not expected to be supported by all fs backends; if some fs backend does not support flags, a fallback to standard renameat() is available. sshfs does not support flags, and thus it fails the rename if flags are passed. Intent is to fail with EINVAL which indicates to mv to go for the fallback. However, the signature of the errno is mistaken, and libfuse can't interpret the value it receives from sshfs_rename; hence it fails with ERANGE instead of EINVAL, which is bogus for mv, thus it gives up, reporting the ERANGE. (The bug was introduced in sshfs 3.0.0, but it got triggered only by the new mv behavior.)


Upstream fixed the bug in sshfs 3.5.0: https://github.com/libfuse/sshfs/commit/6480b66

Comment 4 joshua 2019-01-28 02:14:32 UTC
Can we get a fix for this?  This is a rather crippling bug.

Comment 5 JM 2019-02-06 11:39:22 UTC
Any change to get in the near future a new mv package to fix this bug?

Comment 6 Fedora Update System 2019-02-06 14:36:10 UTC
fuse-sshfs-3.5.1-1.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2019-200e6036d3

Comment 7 Scott Baker 2019-02-08 16:46:29 UTC
Came here to report this as a bug. Downloaded fuse-sshfs-3.5.1-1.fc29 and it does indeed fix the problem. Thank you!

Comment 8 Fedora Update System 2019-02-10 04:27:28 UTC
fuse-sshfs-3.5.1-1.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-200e6036d3

Comment 9 Fedora Update System 2019-02-12 02:55:49 UTC
fuse-sshfs-3.5.1-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.