Seems last upgrade broke umount.cifs:
% # mount -t cifs
//linux/share on /home/user/share type cifs (rw,mand)
% # umount /home/user/share (or umount.cifs /home/user/share)
This utility only unmounts cifs filesystems
and the volume isn't unmounted.
And it's stale, so I'd need to umount+mount but seems my only option is
to reboot (can't do now, remote multi user system).
system is apt-updated Etch, except kernel which is
2.6.22.14-toi3.0rc3-dm-sa-k7.3
Not sure it's last codefix though: I tried 3.0.28 from a Slackware system
with same result. What's up then with {smb,cifs}fs?
thanks
--
paolo
--
To UNSUBSCRIBE, email to debian-bugs-...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
hm, seems the problem is in
mount: mount-2.12r
as it sees the mentioned cifs mounted volume whereas there is none
(/proc/mounts did not list it).
Still, there's something weird with umount.cifs: if I (really) mount the
remote volume, the command succeeds, but then umount hangs.
But <Ctrl-C> can abort it, then the volume *is* unmounted.
So umount succeeds as well, but the utils fail to get the actual (u)mounted
status.
I'm usure who to blame here - umount or umount.cifs - but that breaks
scripts. Bugging mount, since I see that mount/umount -ing the cifs volume
keeps incrementing the corresponding line count in mtab ...
Not smbfs-related, after all; should be reassigned to pkg mount - sorry
for the noise.
thanks
--
paolo
GPG/PGP id:0x1D5A11A4 - 04FC 8EB9 51A1 5158 1425 BC12 EA57 3382 1D5A 11A4
- 9/11: the outrageous deception and ongoing coverup: http://911review.org -
On Wed, Jan 16, 2008 at 11:14:19AM +0100, Paolo wrote:
> Package: smbfs
> Version: 3.0.24-6etch9
> Severity: important
> Seems last upgrade broke umount.cifs:
> % # mount -t cifs
> //linux/share on /home/user/share type cifs (rw,mand)
> % # umount /home/user/share (or umount.cifs /home/user/share)
> This utility only unmounts cifs filesystems
> and the volume isn't unmounted.
> And it's stale, so I'd need to umount+mount but seems my only option is
> to reboot (can't do now, remote multi user system).
> system is apt-updated Etch, except kernel which is
> 2.6.22.14-toi3.0rc3-dm-sa-k7.3
> Not sure it's last codefix though: I tried 3.0.28 from a Slackware system
> with same result. What's up then with {smb,cifs}fs?
On Wed, Jan 16, 2008 at 05:18:16PM +0100, Paolo wrote:
> hm, seems the problem is in
> mount: mount-2.12r
> as it sees the mentioned cifs mounted volume whereas there is none
> (/proc/mounts did not list it).
From your description, this sounds like a bug that was fixed in the upload
of 3.0.25b-2:
* cifs-umount-trailing-slashes.patch: canonicalize mount point names when
umount.cifs is called, to avoid unnecessarily leaving entries behind in
/etc/mtab if invoked with a trailing slash in the mount point name
> Still, there's something weird with umount.cifs: if I (really) mount the
> remote volume, the command succeeds, but then umount hangs.
> But <Ctrl-C> can abort it, then the volume *is* unmounted.
Does it hang before or after the point that the share is unmounted? (Can be
checked from another console using cat /proc/mounts)
Can you send strace output of this unmount attempt? After you hit CTRL-C,
does /etc/mtab get updated, or does the unmount command terminate
immediately?
> So umount succeeds as well, but the utils fail to get the actual (u)mounted
> status.
> I'm usure who to blame here - umount or umount.cifs - but that breaks
> scripts. Bugging mount, since I see that mount/umount -ing the cifs volume
> keeps incrementing the corresponding line count in mtab ...
> Not smbfs-related, after all; should be reassigned to pkg mount - sorry
> for the noise.
Disagree, I think this entirely an smbfs bug.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
sounds close indeed, though I did not use a trailing '/'.
> Does it hang before or after the point that the share is unmounted? (Can be
> checked from another console using cat /proc/mounts)
after. BTW, 'ps x' shows:
20192 ? D 0:00 /sbin/umount.cifs /home/user/share
> Can you send strace output of this unmount attempt? After you hit CTRL-C,
attached
> does /etc/mtab get updated, or does the unmount command terminate
> immediately?
seems the latter: num.lines keep growing with mount/umount cycles.
> > Not smbfs-related, after all; should be reassigned to pkg mount - sorry
> > for the noise.
>
> Disagree, I think this entirely an smbfs bug.
yep, partly agree here: turns out there's something wrong with umount.cifs
indeed, though [u]mount(8) is fooled by mtab while it should dbl-check
with a more reliable
On Sat, Jan 03, 2009 at 07:24:02PM +0000, Debian Bug Tracking System wrote:
> Version: 2:3.2.4-1
> I can't reproduce that bug with 3.2.5, 3.2.4 and 3.3.0-rc2 packages.
> I can reproduce it with the packages in Etch, so it was probably fixed
> somewhere in the early 3.2 releases.
This is disingenuous; the bug you're reproducing is not the one reported by
the bug submitter.
If we're closing this bug, I guess that's ok, but we're closing it because
it's not reproducible at all - not because we know it's fixed in later
versions.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slan...@ubuntu.com vor...@debian.org
--