> -----Message d'origine-----
> De: Steve Haslam [mailto:[EMAIL PROTECTED]]
> Date: mardi 11 janvier 2000 02:37
> �: [EMAIL PROTECTED]
> Objet: autofs and samba...
>
>
> This is probably something you get a lots of complaints about- but
> this email is actually a contribution of real code I've written to get
> Samba shares automounting. Knowing my luck, it's duplicated something
> someone else has done, but hey, it was fun...
I've also worked on this problem in my (internal)
version 0.2 of autofs_slashnet, but I've bumped
on samba 2.0.5 limitation (no gid=/uid=, even with a mount.smb script) ...
> Anyway. My problem being that the smbmount script supplied in the
> latest Samba didn't work with the existing mount_smbfs,
I've a working one for 2.0.5, but you seem to use
the latest samba smbmount that support directly mountoptions
(they say you can just ln -s /bin/smbmount /sbin/mount.smb)
> The answer to that is "probably", but the way I've gone for now is
> that it simply looks in ".auto-samba.passwd" for my password. So my
> situation now is that I can do
>
> echo "shaslam@server xyzzy" > ~/.auto-samba.passwd
in older mount.smb script there was the uuname=unixname that
was asking to read a ~unixname/.smb-pass to find the password.
as you say, it is a must!
the only better way would be an unreadable shadow map with a password
changing
command like "/bin/passwd"... quite complex.
another needed functionality is to support host
or share wildcards (at least the any "*" wildcard),
and prioriy rules.
telling that my password
is by default "DOM/gandalf" except on "bigiron" server
where it is "local/lord", and except on any //*/demo share
where the user is DOM2/guest with "dummy" password...
dissociating NT user name and domain from unix user name, is also important
as you say.
this lead me to implement a wildcard matching in
may derived version ou /sbin/mount.smb...
> and then go to /samba/shaslam@server/sharename, which is much better.
>
> But, woe is me, things *still* aren't right. Because autofs runs as
> root, the views of the Samba shares are owned by root. It might be a
> Good Thing for lookup_samba to automatically set the mount options to
> have them owned by me automatically, but it might not. I've veered
> toward caution here and not put support for that in. But this is where
> we start to make use of nested autofs mounts. Let's change
> /etc/auto.samba to read:
>
> * -fstype=autofs,-Duser=& file:/etc/auto.sambasub
by the way, the -Dvariable=value seems to work for you, which autofs
version do you use ... I did'nt get to make them work.
today the only way I've found to transfer parameters
is to use the current working directory name.
> and this introduces /etc/auto.sambasub, which reads:
>
> * -fstype=autofs
> samba,${user}@&;uid=${user},gid=${user},fmask=0600,dmask=0700
and finally,
would'nt it be better to implement the password finding
in the mount process and not in autofs...
the advantage would be that the password finding
would also forks for static mount which is also important.
my opinion is that mount.smb should support a kind of password fetching
that avoid divulgating it in the command line...
anyway one could make a script that fetch the password
(like the one proposed in samba samples),
and this would be more flexible until a widespread way
can be hardwired in smbmount.
another idea, is that program maps may be sufficient
to implement this, without adding a new map type
for each file system...
do you see reasons that make program maps
unuseable for such work?
performance may be an issue ?
however there is a need for a samba (or nfs)
active host map.
btw, thanks for the code...
8)
