> Ok. I had to poke at this a bit, but finally was able to connect to a
> guest
> share with mount.cifs. The key is to use -o sec=none instead of -o guest.
> According to both the old smbmount manpage and the mount.cifs manpage, the
> "guest" option only means "don't prompt for a password", which is
> apparently
> not sufficient to cause mount.cifs to attempt an anonymous connection.
>
> I suppose we could at least add code to the smbmount wrapper script to
> translate "-o guest" to "-o guest,sec=none".
That might be one option, or at least some sort of documentation to help
the user make the transition to cifs, like ..doc/samba/diagnosis.html -
but that is for the samba package... and we need something for smbfs.
The man page does mention the "sec=none" option, but it's not obvious that
simply using "-o guest" is not enough.
I was going to make a new bug report as this one has gone off-topic, but
right now if testing became the new stable, there might be a certain
percentage of users no longer be able to mount their smbfs shares.
>From the client side, sec=none seems like the right thing to do. Whether
this is the job of the wrapper script or not and if there any disadvantage
in implementing this I'll leave to others to decide.
Maybe a warning message during the smbfs package upgrade is needed... do
people ever read those warning messages? ;-)
>> Note - in my case, the same machine is smb client and server. However,
>> without "security = share" a windows pc on the same subnet is unable to
>> see the shares either. The windows user is prompted for a username and
>> password. So it looks like a server problem to me.
>
> Right, it's a server problem in a sense; see the "map to guest" option in
> smb.conf(5), you probably want (at least) map to guest = bad user.
For me the solution was a little more complicated...
When I first installed samba I did almost the minimum changes from default...
- choose workgroup name
- choose encypt passwords = yes
- some unnecessary parameters removed
- some unnecessary shares removed
- new shares defined.
So I ended up with smb.conf like this...
[global]
workgroup = samba
server string = %h server
dns proxy = no
log file = /var/log/samba/log.%m
max log size = 1000
syslog = 0
panic action = /usr/share/samba/panic-action %d
security = user
encrypt passwords = true
passdb backend = tdbsam
obey pam restrictions = yes
guest account = nobody
invalid users = root
[cdrom]
comment = Samba server CD-ROM
path = /cdrom
writable = no
locking = no
public = yes
The following three methods all worked (allowed mount -f cifs)...
A. start with the smb.conf above and change "security = share"
- but not a good option in many cases.
B. start with smb.conf above and add "map to guest = bad password"
- also not a good option according to smb.conf man page.
C. start with smb.conf above and comment out "passdb backend = tdbsam"
and add "map to guest = bad user"
Simply adding "map to guest = bad user" didn't work on it's own, unless I
removed/commented out "passdb backend = tdbsam" (default is smbpasswd).
Removing "encrypt passwords = true" option didn't help either.
Finally I did one more test...
1. stop samba
2. edit smb.conf above and use options
security = user
passdb backend = tdbsam
map to guest = bad user
3. move/remove all /var/lib/samba/*.tdb files.
4. start samba.
When samba starts it recreates all the /var/lib/samba/*.tdb files. Now I
can mount with "mount.cifs //server/share /mnt -o guest", even though I'm
back to using "passdb backend = tdbsam".
I'm not sure what was happening there... but it's worth noting that for
some people, the "map to guest = bad user" option will not be enough on
it's own.
Best Regards
Alex Jenner
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
