smb.conf file: -------------- [global] workgroup = MIDEARTH netbios name = HOBBIT security = SHARE [data] comment = Data path = /export guest only = Yes Instructions: ============= 1. Remove ALL .tdb file including secrets.tdb - if they exist 2. start samba (smbd, nmbd only) 3. Run smbclient -L localhost -U% Error is: --------- protocol negotiation failed 4. Now edit smb.conf to add: idmap uid = 1000-1100 idmap gid = 1000-1100 Restart samba (smbs, nmbd, winbind) Result is it works! Conclusion: =========== A Simple site must run winbind! Andrew Bartlett says: --------------------- [18:59:27] <jht> I found that I need: passdb backend = guest [18:59:32] <abartlet> yep [18:59:35] <abartlet> you always need that [18:59:45] <jht> But I also need idmap uid/gid or it will not play with me [18:59:56] <jht> I am usingsecurity = share. [19:00:19] <jht> And if winbindd is not running then this guest mode access does not work. [19:00:25] <abartlet> ok - that's a bug [19:00:32] <jht> Ah! [19:00:40] <abartlet> winbind should only be needed when you are running in an NT domain, and want those users [19:00:49] <abartlet> any other requirement for winbind is a bug [19:01:01] <abartlet> (or if you are running pam_winbind etc) [19:01:05] <jht> Ok. So how do I report that? [19:01:43] <abartlet> file it in bugzilla for now, but try to track down what's using it [19:02:02] <jht> So then, what is the most minimum config for guest only read only access to a share? [19:02:19] <jht> Do we even need the "passdb backend" in smb.conf? [19:02:42] <abartlet> the default should work [19:02:53] <jht> So default is: [19:03:18] <jht> no netbios name, no workgroup, no global section? [19:03:42] <abartlet> should work... [19:03:50] abartlet thinks it won't but it should... [19:04:34] <jht> Ah, but that creates user mode. [19:04:45] <jht> So, we do need global. [19:06:42] <abartlet> well, I like your 'map to guest' torture test...
Just worked on this some more. Winbindd does NOT need to be running. The sole requirement is for "idmap uid/gid" to be defined in smb.conf. Note: Once the tdb files have been populated with a working configuration the removal of the "idmap uid/gid" can be affected without problem. The difference is in the contents of the idmap.tdb file! Here is the idmap.tdb that was formed WITHOUT "idmap uid/gid": -------------------------------------------------------------- linux:/var/lib/samba # smbclient -L localhost -U% protocol negotiation failed linux:/var/lib/samba # tdbdump idmap.tdb { key = "UID 65534\00" data = "S-1-5-21-3409129159-854989897-4277649480-501\00" } { key = "S-1-5-21-3409129159-854989897-4277649480-501\00" data = "UID 65534\00" } { key = "IDMAP_VERSION\00" data = "\02\00\00\00" } Here is the idmap.tdb created WITH "idmap uid/gid" defined in smb.conf: ----------------------------------------------------------------------- linux:/var/lib/samba # tdbdump idmap.tdb { key = "USER HWM\00" data = "\E8\03\00\00" } { key = "S-1-5-21-3409129159-854989897-4277649480-514\00" data = "GID 65533\00" } { key = "UID 65534\00" data = "S-1-5-21-3409129159-854989897-4277649480-501\00" } { key = "GID 65533\00" data = "S-1-5-21-3409129159-854989897-4277649480-514\00" } { key = "S-1-5-21-3409129159-854989897-4277649480-501\00" data = "UID 65534\00" } { key = "GROUP HWM\00" data = "\E8\03\00\00" } { key = "IDMAP_VERSION\00" data = "\02\00\00\00" } Once these entries have been created in idmap.tdb, there is no longer a need for the "idmap uid/gid" entries in smb.conf. I do believe this is broken behaviour. Ce n'est pas mes amies?
I've applied a patch to remove the dependence on the idmap uid/gid. JHT has indicated (on IRC) he can no longer reproduce, so I've closed this bug
originally reported against 3.0.0beta1. CLeaning out non-production release versions.
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.