rsync rename operation not permitted with SSHFS

Bug #501532 reported by T McCool
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
rsync
Invalid
Medium
rsync (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Binary package hint: rsync

I have a SSHFS mounted volume and when using rsync (ex: rsync -av /home/me/ /ssfsvolume) to copy files to this volume I receive the following error message:

rsync: rename "/home/me/.foo.txt.jUTKCx" -> "foo.txt": Operation not permitted (1)

It appears to be related to some sort of permission problems related to either SSHFS or rsync in managing the file. In this case it appears rsync has named a temporary file to transmit the file and then it attempts to rename it to the correct name once it is copied and the error message occurs. There is already a file with that name on that volume in this case.

I don't know if the problem is some sort of compatibility with rsync or SSHFS - a permission problem or a configuration problem.

uname -a
Linux moerder 2.6.31-16-generic #53-Ubuntu SMP Tue Dec 8 04:01:29 UTC 2009 i686 GNU/Linux

lsb_release -rd
Description: Ubuntu 9.10
Release: 9.10

rsync --version
rsync version 3.0.6 protocol version 30
Copyright (C) 1996-2009 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
    64-bit files, 64-bit inums, 32-bit timestamps, 64-bit long ints,
    socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
    append, ACLs, xattrs, iconv, symtimes

rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.

sshfs --version
SSHFS version 2.2
FUSE library version: 2.7.4
fusermount version: 2.7.4
using FUSE kernel interface version 7.8

Any suggestions?

Revision history for this message
T McCool (tjmcwiz) wrote :
Download full text (3.4 KiB)

Some additional information:

I set up a simple test with more verbose output from rsync below. It seems that the rename fails but a copy would work. Don't know if that means it is something with SSHFS now or not. Is there a way to 'force' RSYNC to always copy a file?

rsync -avvvv $HOME/rtest/ $HOME/Net/rtest
cmd=<NULL> machine=<NULL> user=<NULL> path=/home/fred/Net/rtest
cmd[0]=. cmd[1]=/home/fred/Net/rtest
note: iconv_open("UTF-8", "UTF-8") succeeded.
(Client) Protocol versions: remote=30, negotiated=30
(Server) Protocol versions: remote=30, negotiated=30
sending incremental file list
[sender] make_file(.,*,0)
[sender] make_file(file.two,*,2)
[sender] make_file(file.one,*,2)
[sender] flist start=1, used=3, low=0, high=2
[sender] i=1 /home/fred/rtest ./ mode=040755 len=4096 uid=1000 gid=1000 flags=5
[sender] i=2 /home/fred/rtest file.one mode=0100644 len=7 uid=1000 gid=1000 flags=0
[sender] i=3 /home/fred/rtest file.two mode=0100644 len=4 uid=1000 gid=1000 flags=0
send_file_list done
file list sent
send_files starting
server_recv(2) starting pid=8128
received 3 names
[receiver] flist start=1, used=3, low=0, high=2
[receiver] i=1 0 ./ mode=040755 len=4096 gid=1000 flags=5
[receiver] i=2 1 file.one mode=0100644 len=7 gid=1000 flags=0
[receiver] i=3 1 file.two mode=0100644 len=4 gid=1000 flags=0
recv_file_list done
get_local_name count=3 /home/fred/Net/rtest
generator starting pid=8128
delta-transmission disabled for local transfer or --whole-file
recv_generator(.,0)
recv_files(3) starting
send_files(0, /home/fred/rtest/.)
recv_generator(.,1)
recv_generator(file.one,2)
send_files(2, /home/fred/rtest/file.one)
count=0 n=0 rem=0
send_files mapped /home/fred/rtest/file.one of size 7
calling match_sums /home/fred/rtest/file.one
file.one
sending file_sum
false_alarms=0 hash_hits=0 matches=0
sender finished /home/fred/rtest/file.one
recv_generator(file.two,3)
recv_files(.)
send_files(3, /home/fred/rtest/file.two)
count=0 n=0 rem=0
send_files mapped /home/fred/rtest/file.two of size 4
calling match_sums /home/fred/rtest/file.two
file.two
sending file_sum
false_alarms=0 hash_hits=0 matches=0
sender finished /home/fred/rtest/file.two
recv_files(file.one)
generate_files phase=1
recv mapped file.one of size 6
data recv 7 at 0
got file_sum
set modtime of .file.one.S1dlNG to (1262142762) Tue Dec 29 22:12:42 2009
renaming .file.one.S1dlNG to file.one
rsync: rename "/home/fred/Net/rtest/.file.one.S1dlNG" -> "file.one": Operation not permitted (1)
recv_files(file.two)
recv mapped file.two of size 4
data recv 4 at 0
got file_sum
set modtime of .file.two.DXXjW4 to (1262142749) Tue Dec 29 22:12:29 2009
renaming .file.two.DXXjW4 to file.two
rsync: rename "/home/fred/Net/rtest/.file.two.DXXjW4" -> "file.two": Operation not permitted (1)
send_files phase=1
touch_up_dirs: . (0)
set modtime of . to (1262142781) Tue Dec 29 22:13:01 2009
recv_files phase=1
generate_files phase=2
send_files phase=2
send files finished
total: matches=0 hash_hits=0 false_alarms=0 data=11
recv_files phase=2
generate_files phase=3
recv_files finished
generate_files finished
client_run waiting on 8128

sent 179 bytes received 53 bytes 464.00 bytes/sec
total size is 11 speedup is 0.05
_...

Read more...

Revision history for this message
T McCool (tjmcwiz) wrote :

Using the command in the test example from the prior comment like:

rsync -avvvv --inplace $HOME/rtest/ $HOME/Net/rtest

Seems to work around the rename issue by writing the remote file in place. It does have the undesirable property of leaving the remote file in an unknown state if something happens to the rsync operation.

Still don't have any better insights into the 'permissions' or 'configuration' issue. Don't understand why the 'copy' will work but the 'rename' will not.....

Revision history for this message
T McCool (tjmcwiz) wrote :

I'm going to close this out for this binary package.

There appears to be a work-around for SSHFS where you can add an option called -oworkaround=rename that will work. I don't know all the downsides of this --- it states some information regarding the operation will no longer be atomic as required by POSIX. It was posted back in 2006 but the option appears to still work and appears to be unrelated to RSYNC.

Mihai Capotă (mihaic)
Changed in rsync (Ubuntu):
status: New → Invalid
Changed in rsync:
status: Unknown → Invalid
Changed in rsync:
importance: Unknown → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.