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
(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.
(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.
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?
Ah, nvm. As soon as the mount points are entered, the permissions are fixed. Thanks for the help.
(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.