Bug 812550

Summary: fuse-sshfs hangs when mounting directory
Product: [Fedora] Fedora Reporter: Mads Villadsen <maxx>
Component: fuse-sshfsAssignee: Peter Lemenkov <lemenkov>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 17CC: fergzzzzzz, jabapi, jokajak, lemenkov, mkasik
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-19 20:06:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mads Villadsen 2012-04-14 18:56:49 UTC
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,

Comment 1 Mads Villadsen 2012-04-14 19:09:20 UTC
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,

Comment 2 Janne Pikkarainen 2012-04-17 08:27:10 UTC
@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.

Comment 3 Janne Pikkarainen 2012-04-17 11:27:05 UTC
A self-compiled fuse-sshfs-2.4 also hangs.

Comment 4 Fergz 2012-04-17 14:22:45 UTC
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

Comment 5 Peter Lemenkov 2012-04-19 20:06:52 UTC

*** This bug has been marked as a duplicate of bug 812798 ***