Bug 496415

Summary: sshfs through autofs doesn't work
Product: [Fedora] Fedora Reporter: Ben Boeckel <fedora>
Component: autofsAssignee: Ian Kent <ikent>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: rawhideCC: ikent, jmoyer
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-04-28 16:27:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Ben Boeckel 2009-04-18 20:27:33 UTC
Description of problem:
I have the following line in my /etc/auto.master:

/mnt/ssh /etc/auto.sshfs uid=500,gid=500,--timeout=30,--ghost

and /etc/auto.sshfs:

subdir   -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536 :sshfs\#user@host\:

I have 2 Rawhide installs and both act differently. On the laptop (which has had Rawhide, but only recently autofs/sshfs) creates the mount point, but it is inaccessible. On here, /mnt/ssh is empty. The manual sshfs command works as expected.

In addition, the permissions are set to be root:root despite the uid and gid being specified in the auto.master file.

Version-Release number of selected component (if applicable):
autofs-5.0.4-24.x86_64
fuse-sshfs-2.2-2.fc11.x86_64

How reproducible:
Always

Comment 1 Ian Kent 2009-04-28 03:51:39 UTC
(In reply to comment #0)
> Description of problem:
> I have the following line in my /etc/auto.master:
> 
> /mnt/ssh /etc/auto.sshfs uid=500,gid=500,--timeout=30,--ghost
> 
> and /etc/auto.sshfs:
> 
> subdir   -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536
> :sshfs\#user@host\:
> 
> I have 2 Rawhide installs and both act differently. On the laptop (which has
> had Rawhide, but only recently autofs/sshfs) creates the mount point, but it is
> inaccessible. On here, /mnt/ssh is empty. The manual sshfs command works as
> expected.
> 
> In addition, the permissions are set to be root:root despite the uid and gid
> being specified in the auto.master file.

The options in the master map are mount options, that with the
default configuration, are appended to options given in the
map entry. The mount point directory is a directory in the
autofs pseudo file system so its owner will always be root:root
until something is mounted on it.

I started out to try and duplicate this but I can't see how
I can set this up, given the information you've provided.

Can you describe how you think this is supposed to work.

Comment 2 Ian Kent 2009-04-28 09:23:26 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Description of problem:
> > I have the following line in my /etc/auto.master:
> > 
> > /mnt/ssh /etc/auto.sshfs uid=500,gid=500,--timeout=30,--ghost
> > 
> > and /etc/auto.sshfs:
> > 
> > subdir   -fstype=fuse,rw,nodev,nonempty,noatime,allow_other,max_read=65536
> > :sshfs\#user@host\:
> > 
> > I have 2 Rawhide installs and both act differently. On the laptop (which has
> > had Rawhide, but only recently autofs/sshfs) creates the mount point, but it is
> > inaccessible. On here, /mnt/ssh is empty. The manual sshfs command works as
> > expected.

If you have the --ghost option and the directory in /mnt/ssh is
not present check that /etc/auto.sshfs does not have the execute
mode set.

snip ...

> 
> I started out to try and duplicate this but I can't see how
> I can set this up, given the information you've provided.
> 
> Can you describe how you think this is supposed to work.  

OK, I get it, sshfs is supposed to put up a dialog asking for the
passphrase. But, in the messages log on a Rawhide install we see:

Apr 28 17:07:07 rawhide-i386 automount[1654]: mount_mount: mount(generic): calling mount -t fuse -s -o uid=500,gid=500,rw,nodev,nonempty,noatime,allow_other,max_read=65536 sshfs#raven@budgie: /mnt/ssh/subdir
Apr 28 17:07:07 rawhide-i386 kernel: sshfs[1666] general protection ip:e2b237 sp:bfce9848 error:0 in libc-2.9.90.so[dfe000+16b000]
Apr 28 17:07:07 rawhide-i386 automount[1654]: >> GThread-ERROR **: file gthread-posix.c: line 140 (g_thread_impl_init): error 'Operation not permitted' during 'pthread_getschedparam (pthread_self(), &policy, &sched)'
Apr 28 17:07:07 rawhide-i386 automount[1654]: >> aborting...
Apr 28 17:07:07 rawhide-i386 automount[1654]: mount(generic): failed to mount sshfs#raven@budgie: (type fuse) on /mnt/ssh/subdir

which doesn't look like an autofs problem to me since the current
CVS revision of autofs (rev 26) works fine on F-10 with the same
map entries and the changes between 24 and 26 don't affect this
area of the code.

You should confirm you are seeing a similar message is in the
messages log before we consider re-assigning this bug.

Comment 3 Ben Boeckel 2009-04-28 15:35:33 UTC
Ah. auto.sshfs was executable (probably due to it being saved on vfat between installs, I should probably back up a tarball of files, not just the files themselves...). I have the key for this as password-less (it's locked under root  password and encrypted on mobile disks), so I never expected a password entry box to pop up. It now works (though permissions are not for some reason). Why would it being executable cause it to not work? Here's how permissions are(n't) working:

(autofs is stopped)
drwxr-xr-x   2 boeckb boeckb 4096 2009-04-18 16:26 ssh

(autofs is running)
drwxr-xr-x   6 root   root      0 2009-04-28 11:33 ssh

# ll /mnt/ssh
total 0
dr-xr-xr-x 2 root root 0 2009-04-28 11:34 ccni.rpi
dr-xr-xr-x 2 root root 0 2009-04-28 11:34 cledwyn
dr-xr-xr-x 2 root root 0 2009-04-28 11:34 cs.rpi
dr-xr-xr-x 2 root root 0 2009-04-28 11:34 kokanee

Shouldn't these be writable (rw option in auto.sshfs) and owned by my user/group?

Comment 4 Ben Boeckel 2009-04-28 16:27:28 UTC
Ah, nvm. As soon as the mount points are entered, the permissions are fixed. Thanks for the help.

Comment 5 Ian Kent 2009-04-29 01:26:56 UTC
(In reply to comment #4)
> Ah, nvm. As soon as the mount points are entered, the permissions are fixed.
> Thanks for the help.  

That's right.
When the mount point directories don't actually have an active
mount they get pre-set permissions. Since only the automount
daemon can do anything in the autofs pseudo filesystem the
permission you see is sensible. Of course, once they have a
mount on top of them you see the mode of the mounted file system
instead which is what your expecting.