Package: autofs5
Version: 5.0.4-3
Severity: normal
I'm using autofs for several mounts, including an USB key and some sshfs
mounts. The relevant parts of the config files are the following:
,----[ auto.master ]
| /mnt/auto/removable /etc/auto.removable --timeout=30
| /mnt/auto/fuse /etc/auto.fuse --timeout=900
`----
,----[ auto.removable ]
| usb-keys -fstype=ext3,ro,noatime,nodev,noexec,nosuid
:/dev/usb-key-lacie-keys
`----
,----[ auto.fuse ]
| musique
-fstype=fuse,rw,nosuid,nodev,max_read=65536,user=roland,IdentityFile=/home/roland/.ssh/id_rsa,ServerAliveInterval=60,uid=1000,allow_other,gid=1000
sshfs\#rol...@mirenboite:/srv/musique
| servomir-shared
-fstype=fuse,rw,nosuid,nodev,max_read=65536,user=roland,IdentityFile=/home/roland/.ssh/id_lolando2008,ServerAliveInterval=60,uid=1000,allow_other,gid=1000,port=40022
sshfs\#rol...@servomir.placard.fr.eu.org:/home/roland/shared
`----
The USB key automounts fine, and so does the "musique" sshfs volume.
The "servomir-shared" volume, however, fails. stracing the automount
process and running the same mount command by hand in a shell gets the
volume mounted, but it fails with the following messages when run by
automount:
,----
| Nov 18 10:03:50 mirexpress automount[27133]: >> read: Connection reset by peer
| Nov 18 10:03:50 mirexpress automount[27133]: mount(generic): failed to mount
sshfs#rol...@servomir.placard.fr.eu.org:/home/roland/shared (type fuse) on
/mnt/auto/fuse/servomir-shared
`----
The difference with the "musique" share seems to be the location of
the SSH key: /home/roland/.ssh/id_rsa is stored locally, but
/home/roland/.ssh/id_lolando2008 is actually a symbolic link to
/mnt/auto/removable/usb-keys/roland/.ssh/id_lolando2008. My usual ssh
processes trigger the automount fine, and doing an ls -l works too, but
it seems to fail when run by autofs itself. Replacing the symlink with
the actual location in auto.fuse doesn't help, and further stracing
shows the following:
,----
| [pid 28139] open("/mnt/auto/removable/usb-keys/roland/.ssh/id_lolando2008",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
`----
I believe there's a bug somewhere, since that file really does exist.
Can automount itself not access files stored in automounted places? Is
it chrooted or so?
Roland.
-- System Information:
Debian Release: squeeze/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.31-1-686 (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages autofs5 depends on:
ii libc6 2.10.1-7 GNU C Library: Shared libraries
ii ucf 3.0024 Update Configuration File: preserv
Versions of packages autofs5 recommends:
ii module-init-tools 3.11-1 tools for managing Linux kernel mo
ii nfs-common 1:1.2.0-4 NFS support files common to client
autofs5 suggests no packages.
-- no debconf information
--
Roland Mas
The more it stays the same, the less it changes.
-- in The Majesty Of Rock (Spinal Tap)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
