[Pkg-samba-maint] Bug#455479: failed to mount smbfs shares: mount error 13 = Permission denied

[Tim Rühsen]

Am Mittwoch, 12. Dezember 2007 schrieb Steve Langasek:
> forcemerge 369495 455479
> thanks
>
> On Mon, Dec 10, 2007 at 12:09:24PM +0100, Tim Rühsen wrote:
> > Am Montag, 10. Dezember 2007 schrieb Steve Langasek:
> > > On Mon, Dec 10, 2007 at 11:51:39AM +0100, Tim Ruehsen wrote:
> > > > mounting shares via smbfs (also tried cifs - same problem) result in:
> > > > mount error 13 = Permission denied
> > > >
> > > > the systems to mount are different linux systems:
> > > > - current stable
> > > > - 6 years old unstable
> > > > - SuSE 7.1
> > > >
> > > > downgrading just smbfs to 3.0.27a-1 completely removes the problem.
> > > > (dpkg -i --force-all smbfs_3.0.27a-1_i386.deb)
> > > >
> > > > my fstab entries look all the same (for example):
> > > > //dev-3/dev    /network/dev-3/dev  smbfs
> > > > credentials=/etc/credentials.oms,uid=oms,gid=users,noauto,user
> > > >
> > > > the permissions for /network/dev-3/dev are 0777.
> > > > i could not track the problem down (strace, changing permissions on
> > > > the credential file, trying with different users incl. root, changed
> > > > options)
> > >
> > > By any chance, to you have spaces before or after the equal sign in
> > > your credentials file?
> >
> > Whow, good point. You just found the problem:
> > having a space before the username produces the error.
> > having a space before the password seems to be ok.
>
> Ok, then this becomes an instance of bug #369495; merging.
>
> Unfortunately, I have to say that the mount.cifs semantics are the more
> correct because whitespace (including leading whitespace) is significant in
> passwords and trimming whitespace therefore makes it impossible to
> represent some possible passwords in credentials files.  So this bug is
> "wontfix" as far as fully supporting the old syntax, but there is an open
> request for improved documentation.

Please read my above comment:
A leading space before the password does not matter at the moment.
But a leading whitespace in the username matters.

Either, the docs should mention this exception or (maybe better)
we need a fix in software (to make leading spaces work for passwords) together 
with a fix for #369495. It is still an issue for smbfs 3.0.28-1 - i just made 
a test.