Setting up an anonymous public Samba Share to be accessed via Windows 7 and XBMC

Solution 1:

Happened to stumble across this thread on the Ubuntu forums, and thought it might help. It explains the steps that happen behind the scenes:

In Windows the client's username and password is automatically sent when it browses for shares - this is done without the user's knowledge. That forces Samba to deal with the sent credentials even though it's a guest share that requires no authentication.

When that username is passed Samba will search through it's password database for that user:

• If there is no match to the username the client user is tagged a "Bad User" and converted ( mapped ) to the guest account which by default is "nobody".

• If it finds a match to the username and there is a samba password that matches the one sent by the Windows client then the Windows user automatically gains access although not as an anonymous user which is why you needed to add "force user = nobody" to your share definition.

• If it finds a match to the username but the samba password does not match exactly the password that's automatically sent by the Windows client then you will be prompted for a password - even for a guest share.

Try adding force user = nobody to your share definition, and see if that does it.

Edit 02/20/2013:

Is testparm returning an exit code of something other than zero? All the same, I would go ahead and give that area of the config a good, hard look. Also, I'm not sure how case-sensitive smb.conf is, but every example I see (for example) of map to guest = Bad User has the B and U capitalized. Check-out the Samba man pages for the options you are using, and double-check everything.

Solution 2:

This is how OpenElec is configured. Should do what you are asking for. (even if it is a year later...maybe it will help the next one) Just tweak the share settings as needed.

[global]
  server string = YOURSERVERNAME
  workgroup = WORKGROUP
  netbios name = %h
  security = share
  guest account = root
  socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=65536 SO_SNDBUF=65536
  smb ports = 445
  max protocol = SMB2
  min receivefile size = 16384
  deadtime = 30
  os level = 20
  mangled names = no
  syslog only = yes
  syslog = 2
  name resolve order = lmhosts wins bcast host
  preferred master = auto
  domain master = auto
  local master = yes
  printcap name = /dev/null
  load printers = no
  browseable = yes
  writeable = yes
  printable = no
  encrypt passwords = true
  enable core files = no
  passdb backend = smbpasswd
  smb encrypt = disabled
  use sendfile = yes

[share]
comment = Share
path = /share
available = yes
browsable = yes
writable = yes
public = yes

Solution 3:

Since Google search brings us here and there is no clear answer, I summed it up.

Below are the conditions required to make sure SMB clients will not be prompting for the username and password when accessing your Samba server:

1. Add guest account = <owner-of-your-shares> under a [global] section. It is important that the owner account of your shares has an access to them. If you do not do this, Samba will assume the guest account is a nobody user which unlikely has an access to the data in your share.

   Alternatively, you can specify force user = <owner-of-your-share> under your [shareXYZ] block.

2. Make sure your [shareXYZ] has guest ok = yes.

   Set browsable = yes but it is usually inherited from the [global] and is set to yes by default.

Then, probably security = user should be also set (this is default when you do not have Active Directory set in your environment). Though, I am not sure whether this flag is required as I do not have AD in my environment.

Of course, if you want the nobody user to work, then you can just chown -Rh 65534:65534 /yourshare, after that you will be fine just with the single setting guest ok = yes under your [shareXYZ].

Note that having set rwx to others (chmod o+rwx /yourshare) did not let Samba with its nobody user into the share. I have checked this with strace -f -e chdir,geteuid,getegid -p <pid-of-the-parent-smbd-process>. Probably Samba just ignores the permissions set for the others? Not sure.