Your message dated Wed, 28 Dec 2011 00:07:43 +0000
with message-id <[email protected]>
and subject line Bug#653172: Removed package(s) from unstable
has caused the Debian Bug report #571472,
regarding auto.smb: reject unknown shares instead of re-listing available
shares in a sub-directory
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
571472: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571472
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: autofs
Version: 4.1.4+debian-2.1
Severity: important
Tags: patch
Hi,
Let's say I have:
//192.168.1.12/share1
//192.168.1.12/share2
When accessing, e.g.:
/smb/192.168.1.12/share1
I get the content of share1. Good.
But when mouting e.g.:
/smb/192.168.1.12/idontexist
then I get a new folder containing:
$ ls /smb/192.168.1.12/idontexist
share1 share2
AFAICS autofs can map '192.168.1.12/share1' but cannot map
'192.168.1.12/idontexist'. In that last case, it re-runs
/etc/auto.smb with that path, which happily outputs:
-fstype=cifs \
/share1 ://192.168.1.12/idontexist/share1 \
/share2 ://192.168.1.12/idontexist/share2
i.e. this creates 2 new virtual subdirs.
This also happens in a sub-sub-directory for the same reason.
I fixed it by simply adding in auto.smb near the top:
# Don't accept '/' in share names
if echo $key | grep '/' > /dev/null; then
exit
fi
After that autofs correctly understands that the directory is not valid:
$ LANG=C ls /smb/192.168.1.12/idontexist
ls: cannot access /smb/192.168.1.12/idontexist: No such file or directory
(Today I also got a weird issue where a client got dozens of remote
subdirs referenced in `mount`, with the concrete effect that remote
access didn't work; possibly a transient network issue happened, and
autofs got confused or something. Something like:
//192.168.1.12/share1/share1 on /smb/192.168.1.12/share1/share1 type cifs
(rw,mand)
//192.168.1.12/share1/share2 on /smb/192.168.1.12/share1/share2 type cifs
(rw,mand)
//192.168.1.12/share1/mydir/share1 on /smb/192.168.1.12/mydir/share1 type cifs
(rw,mand)
//192.168.1.12/share1/mydir/share2 on /smb/192.168.1.12/mydir/share2 type cifs
(rw,mand)
...
I had to make the client reboot to fix the situation. I suspect that
the above safety check would have helped in that case too.)
-- System Information:
Debian Release: 5.0.4
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-2-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 autofs depends on:
ii libc6 2.7-18lenny2 GNU C Library: Shared libraries
ii ucf 3.0016 Update Configuration File: preserv
Versions of packages autofs recommends:
ii module-init-tools 3.4-1 tools for managing Linux kernel mo
pn nfs-common <none> (no description available)
autofs suggests no packages.
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 4.1.4+debian-3+rm
Dear submitter,
as the package autofs has just been removed from the Debian archive
unstable we hereby close the associated bug reports. We are sorry
that we couldn't deal with your issue properly.
For details on the removal, please see http://bugs.debian.org/653172
The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.
This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
[email protected].
Debian distribution maintenance software
pp.
Luca Falavigna (the ftpmaster behind the curtain)
--- End Message ---
