On Thu, 26 Apr 2001, Dirk Maa� wrote:
> "H. Peter Anvin" wrote:
> >
> >
> > You're supposed to be able to backshash-escape the spaces, but I'm not
> > really sure if it will work. I'm ALSO not sure that mount.smbfs won't
> > mangle the string. Think about a password with a comma in it...
> >
>
> backslash-escaped space didn't help.
Autofs doesn't do \ escape on anything(?). Try specifying a smb share with
space in it. More on this below.
> The line:
> mount.smbfs //gw/admin /mnt -o username=admin,password=' grxv5?'
> worked well. That's why I was confused about the behavior of autofs.
I'm surprised ...
> I tested a password with a comma in it and mount.smbfs failed, while
> smbclient //gw/admin ' gr,v5?' -U admin
> worked. So it is not only an autofs issue.
... but not at this. Which is a bug of course. gr\,v5 or something like
that should be handled.
Fortunately you can specify passwords in a lot of different ways. smbmount
in samba 2.2.0 should support all the various ways that smbclient uses.
See the smbmount manpage for details.
For strange (good) passwords it may be easiest to use the "credentials"
option from smbmount 2.2.0. It allows you to put username & password in a
separate file (so you could leave the autofs map world readable if you
like).
About parsing:
parse_sun.c:chunklen() will stop at the first space, \ or not. Further
down it has this which will truncate anything:
p[chunklen(p)] = '\0'; /* We don't use anything after the entry */
I changed this once, but it was an ugly hack so I didn't keep it. I know
others on this list have talked about improving the parsing, but I don't
know if that has led to anything.
Does anyone know if autofs4 handles this differently?
foo -fstype=smbfs,guest,uid=puw ://srv/foo bar
foo -fstype=smbfs,guest,uid=puw ://srv/foo\ bar
foo -fstype=smbfs,guest,uid=puw "//srv/foo bar"
or some other construct. Does nfs allow space in names? How does the
solaris automounter handle that?
/Urban, with a procmail rule that put the last month of autofs mails in
the wrong place ... :)
