Description of problem: fuse-sshfs hangs when mounting directory, while a simple ssh to the same server works fine. It has worked fine previously on this F17 installation but now no longer does. There are no selinux warnings. Version-Release number of selected component (if applicable): fuse-sshfs-2.3-2.fc17.x86_64 fuse-2.8.6-3.fc17.x86_64 How reproducible: Always Steps to Reproduce: 1. sshfs someone@somewhere:/somedir /foo/bar Actual results: Hangs Expected results: Mounts the remote directory Additional info: Running sshfs under strace has these lines at the end stat("/home/maxx/Videos/remote-recordings", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 openat(AT_FDCWD, "/home/maxx/Videos/remote-recordings", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 getdents(3, /* 2 entries */, 32768) = 48 getdents(3, /* 0 entries */, 32768) = 0 close(3) = 0 open("/dev/fuse", O_RDWR) = 3 getgid() = 1000 getuid() = 1000 mount("center@phoenix:/storage/recordings", "/home/maxx/Videos/remote-recordings", "fuse.sshfs", MS_NOSUID|MS_NODEV, "max_read=65536,fd=3,rootmode=400"...) = -1 EPERM (Operation not permitted) close(3) = 0 socketpair(PF_FILE, SOCK_STREAM, 0, [3, 4]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f1d98b42a10) = 4839 close(3) = 0 recvmsg(4,
It might be a more general fuse problem. I just tried installing fuse-zip and it hangs in a very similar place according to strace. tat("/home/maxx/Download/TEMP/A", {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0 openat(AT_FDCWD, "/home/maxx/Download/TEMP/A", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4 getdents(4, /* 2 entries */, 32768) = 48 getdents(4, /* 0 entries */, 32768) = 0 close(4) = 0 open("/dev/fuse", O_RDWR) = 4 getgid() = 1000 getuid() = 1000 mount("fuse-zip", "/home/maxx/Download/TEMP/A", "fuse.fuse-zip", MS_NOSUID|MS_NODEV, "fd=4,rootmode=40000,user_id=1000"...) = -1 EPERM (Operation not permitted) close(4) = 0 socketpair(PF_FILE, SOCK_STREAM, 0, [4, 5]) = 0 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f56a3300a10) = 5723 close(4) = 0 recvmsg(5,
@Mads Villadsen: I can verify this happening. Yesterday my sshfs mount was working perfectly. After I upgraded my F17 packages this morning and rebooted my laptop due the kernel upgrade to 3.3.2-1.fc17.x86_64, sshfs stopped working. I even tried to boot to previous kernel (3.3.1-5.fc17.x86_64) to see if it was due the kernel upgrade, no it was not. Now that I read /var/log/yum.log, it seems fuse-libs package was upgraded from fuse-libs-2.8.6-4 to 2.8.7-1 this morning, but fuse-sshfs package remains the same than before (fuse-sshfs-2.3.2), so this definitely seems to be a fuse-libs problem.
A self-compiled fuse-sshfs-2.4 also hangs.
I have the same problems as above. After doing a rather large yum update sshfs stopped working. Downgrading sshfs or fuse didn't help so I went through the list... It appears to be an updated selinux-policy that caused it to stop working, downgrading selinux-policy and selinux-policy-targeted fixed it: # yum downgrade selinux-policy selinux-policy-targeted .......... Running Transaction Installing : selinux-policy-3.10.0-110.fc17.noarch 1/4 Installing : selinux-policy-targeted-3.10.0-110.fc17.noarch 2/4 Cleanup : selinux-policy-targeted-3.10.0-114.fc17.noarch 3/4 Cleanup : selinux-policy-3.10.0-114.fc17.noarch 4/4 Verifying : selinux-policy-3.10.0-110.fc17.noarch 1/4 Verifying : selinux-policy-targeted-3.10.0-110.fc17.noarch 2/4 Verifying : selinux-policy-3.10.0-114.fc17.noarch 3/4 Verifying : selinux-policy-targeted-3.10.0-114.fc17.noarch 4/4 Removed: selinux-policy.noarch 0:3.10.0-114.fc17 selinux-policy-targeted.noarch 0:3.10.0-114.fc17 Installed: selinux-policy.noarch 0:3.10.0-110.fc17 selinux-policy-targeted.noarch 0:3.10.0-110.fc17 Complete! ...... hope the helps Fergz
*** This bug has been marked as a duplicate of bug 812798 ***