[Pkg-samba-maint] Bug#463367: smbfs: Vague error: "mount error 6 = No such device or address"

[Steve Langasek]

On Thu, Jan 31, 2008 at 01:34:17AM -0500, A. Costa wrote:
> Package: smbfs
> Version: 3.0.28-2
> Severity: normal

> Before Debian's recent move from 'smbfs' to 'cifs', these used to work:

>     mount -t smbfs //192.168.1.51/dev/hdb1 /mnt/tmp -o username=knoppix,password=xxxxxx
>     mount.smbfs //192.168.1.51/dev/hdb1 /mnt/tmp -o username=knoppix,password=xxxxxx

Er, and what were they supposed to do, exactly?  Why do you have a share
named "/dev", under which is a directory named "hdb1"?

I don't think subshare mounting ever worked with smbfs, so I'm not sure what
this was ever supposed to do.

> After the move they don't work, even when connecting to the same
> unchanged server.  OK, sometimes syntaxes change...  so I tried
> 'mount.cifs'.

> The 'cifs' error message is confusing:

>     % mount.cifs //192.168.1.51/dev/hdb1 /mnt/tmp -o user=knoppix,password=xxxxxx
>     retrying with upper case share name
>     mount error 6 = No such device or address
>     Refer to the mount.cifs(8) manual page (e.g.man mount.cifs)

> It took over an hour of web searching & trial and error to discover
> the new syntax:

>     % mount.cifs //192.168.1.51/hdb1 /mnt/tmp -o user=knoppix,password=xxxxxx ; echo $?
>     0

Ok, then that looks to me like smbfs was accidentally cutting the share name
at the last '/' for you, so silently translating //192.168.1.51/dev/hdb1
into //192.168.1.51/hdb1.  Please confirm the names of the shares on your
samba server; I suspect you only have an "hdb1" share, not a "dev" share.

> It's almost the same as 'mount.smbfs', except: s/smbfs/cifs/ 
> s,/dev/hdb1,/hdb1, s/username/user/.

The latter is not necessary, and in fact is a documentation bug by advising
people to use this syntax since 'user' has a special meaning in mount
options in /etc/fstab.

> Some observations & suggested revisions, skip ahead to the latter if 'why' is
> less interesting that 'what'...

> Observations on the error message:

>     1) "retrying with upper case share name" -- retrying what?  What verb:
>        connecting, finding, mounting?

Er, all of the above?  Why would you expect there to be a difference between
any of these operations?

>  And what does the program take to be the share name?  Users need specific
> diagnostics.

The share name is taken to be the share name.  I don't think it's the proper
role of mount diagnostic messages to explain CIFS terminology to the user.

>     2) "mount error 6 = ": what does "6" mean?  According to 'man mount':

No, this has nothing to do with 'man mount'.  This is a POSIX errno.

>        Perhaps the "6" is internal to 'mount.cifs'.  Users shouldn't be 
>        distracted; put that in the 'mount.cifs' return code.

No, that's wrong.  It's exposing the kernel error number that resulted from
the mount attempt, which is important diagnostic information and consistent
with other mount programs.

>     3) "no such device or address" -- which is it?  And why 'device'?  
>        Shouldn't it be no such "server name" or no such "samba share name"?  
>        Both nouns "device" and "address" are too general.

This is the text correspondence to the 'ENXIO' POSIX errno (= 6).  If you
have a problem with that, you'll have to take it up with POSIX; mount.cifs
doesn't get a say over the list of available error codes that can be
returned by the kernel.

>        It's extra-confusing for users trying to mount a '/dev' device.

... which was your error.  You were *not* mounting an "/dev" device, you
were mounting a CIFS share.

Have you read documentation somewhere that says you should try to mount
knoppix-exported shares this way?

> General version:

>     % mount -t cifs //192.168.1.51/fubar /mnt/tmp -o user=knoppix,password=xxxxxx
>     No such share name '/fubar'
>     Retry mount with upper case share name...
>     No such share name '/FUBAR'

> This requires the program's internal error checking logic to
> distinguish between server names and share names.  Which it probably
> should, if it doesn't already.

A fine suggestion, but unless you plan to provide a patch, please discuss
this with upstream directly; this is going to be low enough down my todo
list that I'm unlikely to ever work on it.

The share name is also "fubar", not "/fubar".

> User-friendly upgrader's version:

>     % mount -t cifs //192.168.1.51/dev/hdb1 /mnt/tmp -o user=knoppix,password=xxxxxx
>     No such share name '/dev/hdb1'

Incorrect, the share name is "dev".

>     Retry mount with upper case share name...
>     No such share name '/DEV/HDB1'
>     Share name prefix '/dev' in '/dev/hdb1' is valid for deprecated 'smbfs', but not 
>     for 'cifs -- try share name '/hdb1' instead.

No, it's not "valid", it just accidentally works the way you meant it to.

But I think this is an appropriate thing to warn on in the mount.smbfs
wrapper, like all such behavior differences between smbfs and cifs.  I'll
work on implementing this.

Cheers,
-- 
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/
slangasek at ubuntu.com                                     vorlon at debian.org