Description of problem: I am using fuse-sshfs to create an encrypted backup on a remote system in such a way that the owner of the remote system can not read the data. The process writing to the fuse-sshfs share hangs. Version-Release number of selected component (if applicable): fuse-sshfs-1.4-2.fc5 How reproducible: Every time Steps to Reproduce: 1. Mount a fuse-sshfs share, /mnt1 2. /mnt1/peer.img is an encrypted looback filesystem; use losetup, cryptsetup and mount to mount it locally, /mnt2. 3. Use rsync to synchronize local data with /mnt2. Actual results: The rsync process quickly hangs. Once this happens, other operations on /mnt2 will hang. For example, "strace ls -R /mnt2" hangs at: [...] open("lost+found", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3 fstat64(3, {st_mode=S_IFDIR|0700, st_size=16384, ...}) = 0 fcntl64(3, F_SETFD, FD_CLOEXEC) = 0 fstat64(3, {st_mode=S_IFDIR|0700, st_size=16384, ...}) = 0 getdents64(3, <-- HANG HERE. At this point, only rebooting seems to stop these hangs (of course the filesystem is "unmounted" by this action). Expected results: The rsync process should continue until completion. Additional info: The same process works if performed locally without using sshfs. I can backup to an encrypted loopback device that is on the local filesystem. However, backing up to an encrypted loopback device that is mounted using sshfs hangs.
Does it still reproducible with the latest FUSE?
Ping.
To test: sshfs USER@HOST: /tmp/1 dd if=/dev/zero of=/tmp/1/test.img bs=1M count=2 losetup /dev/loop0 /tmp/1/test.img cryptsetup luksFormat /dev/loop0 cryptsetup luksOpen /dev/loop0 foo mount /dev/loop0 /tmp/2 mkfs.ext3 /dev/mapper/foo mount /dev/mapper/foo /tmp/2 rsync -r SOMEDIR /tmp/2/ I checked fuse-sshfs-1.9-2.fc8.ppc and the bug seems to have been fixed in this package.