Turnkey Linux File Server SMB - No Guest Access possible OOB

Welcome to TurnKey and thanks for posting your issue. If nothing else, I'm sure that it will be useful for others.

We're mostly all full time Linux users here at TurnKey and I personally don't have any need for Samba, thus no significant experience with it. Having said that, I have been quite involved in maintaining it and I do fire up a Win10 VM for basic testing when we do a new major release, or when bug fixing. Judging from your post, my guess is that you are much more of a "SMB wizard" than I am! ;)

Regardless, my initial perusal of the smb.conf Debian Bullseye man page (which is relevant to TKL v17.x - equivalent for v16.x is likely the same, but can be explicitly viewed here) is consistent with yours. I.e. to support guest login, you only need to need to set 'guest ok = yes' (no need to comment out "restrict anonymous = 2") - bold is mine:

guest ok (S)
If this parameter is yes for a service, then no password is required to connect to the service. Privileges will be those of the guest account.
This parameter nullifies the benefits of setting restrict anonymous = 2
[...]

And

restrict anonymous (G)
[...]
Setting restrict anonymous = 1 will disable anonymous SAMR access.
Setting restrict anonymous = 2 will, in addition to restricting SAMR access, disallow anonymous connections to the IPC$ share in general. Setting guest ok = yes on any share will remove the security advantage.
[...]

But after a bit more digging and a re-read, I suspect that despite the alluded implication that setting 'guest ok = yes' (or 'public = yes') completely nullifies "restrict anonymous = 2", that it actually doesn't. I think the literal intention of the doc is to note that it just nullifies the security advantage provided (but doesn't fully disable it):

nullifies the benefits of setting restrict anonymous = 2

Setting guest ok = yes on any share will remove the security advantage

I.e. note that neither references actually say that 'guest ok = yes' completely disables 'restrict anonymous = 2', just that it negates the security benefits.

FWIW, I searched fairly wide and far to try to get a handle on this issue. The only bug report I found that seemed relevant (reported in 2014, status "new", no response), suggests to me that the issue is a documentation one rather than a functionality one.

If you want to dig into that some more, then I encourage you to sign up to and post a message on, the Samba mailing list (I suggest the default, general Samba list). If we can confirm the intention, perhaps it's even worth proposing a draft improvement for the man page? Maybe what's there just needs an explicit note that whilst 'guest ok = yes' disables the security provided by 'restrict anonymous = 2', it isn't enough to allow guest access?

Also, apparently (noted in the bug report I linked to above), setting 'restrict anonymous = 1' will allow guest login, but not 'restrict anonymous = 2'. I haven't tested or confirmed that, but thought it worth a mention...

Re "map to guest = Bad User" - yes my reading of the docs is that that is necessary to allow guest access. As you likely read, it says something about this being required because of the order of operations when authenticating and allowing access to resources.

Finally, regarding Webmin. After having a bit of a poke around there, I found reference to "guest access". It looks like it's configured at the share level rather than globally. Although I'm not 100% clear whether that would be enough or not to make it work (following your post, I suspect not). Please check the Webmin Samba module docs for more info.

We package the default upstream Webmin samba module currently, but if there are improvements to be made then we could provide a patch to the Webmin devs to improve it? Or even if we didn't go that way, we could patch it ourselves? Either way, with the amount I have on my plate at the moment it's highly unlikely that I'll have time and space for anything like that anytime soon. If you know any perl, then perhaps you could have a go yourself?

Like you I am mostly a Linux user, along with macos. I do have a limited use case for Samba sharing, which is to a low power Windows htpc--and hardware support for codecs drives that.

I also did a little more research myself and submitted a pull on Github for Turnkey/common. It seems I've stumbled on a mess.

The current situation is a classic example of a GUI to CLI/.conf conflict that has been extenuated by security-minded changes to Samba over the years.

Some years ago [see old docs link below], it was possibly to set a Samba security level of "share" as opposed to "user" (the default level). While that still worked, setting a "guest ok=yes" would override the global "restrict anonymous" parameter (as described in the Samba parameter docs I linked to earlier--and I am not at all surprised to learn that the smb.conf man pages are also likely out of date on this fine a detail as well--though I note there is now no discussion of "share" in the security parameter).

Setting to "security = share" in the smb.conf would now throw an error in the smbd whenever it is started with that parameter value--it is just no longer permitted. Using Samba's "testparm -s" will also confirm this without restarting it. (I don't have a link to support this, but I am certain this was a security-minded change.) So overriding restrict anonymous no longer works as documented (as tested in three distros).

On the GUI side: Webmin still supports "security = share" as an option in its Windows File Sharing panel (that's where the [global] smb.conf settings are changed). But if you change it to share, you cannot restart the samba server will not run--because that level is not longer valid. Perhaps the Webmin devs have left it in place for backwards compatibility, or perhaps this should be fixed.

Webmin also does not seem to have a place to edit the "restrict anonymous" parameter in the GUI. This is something that could indeed be passed onto the Webmin devs on github. Unfortunately I know next to nothing about patching Perl.

However, Webmin does support enabling guest or guest-only access for a specific share in the "[SomeFileShareYouCreated]" --> "Security and Permissions" panel. But... that only sets the "guest ok" or "guest only" parameters in the [share] section of smb.conf. It doesn't fix or at least warn of the conflict with the "restrict anonymous" [global] parameter--probably because it used to be the case that you would set your security to be share level...

So back in the CLI looking at the TKL smb.conf file, this "restrict anonymous" parameter stood out as different in a quick comparison with how OpenMediaVault set up its smb.conf for a guest share that worked as expected. It also turns out this parameter also isn't in the default Debian smb.conf at /usr/share/samba/smb.conf, while "map to guest = bad user" is included there. So this seems to be iconoclastic in TKL, and behind the times or not in keeping with standard (though maybe not best!) practice for Linux Samba configuration.

All this leads me to believe that the smb.conf used in Turnkey/common is the culprit, although Webmin could certainly also be smarter. My proposed change to TKL will make the Turnkey File Server work as Webmin--and a naive user--expects, although the drawback is that TKL would default to the possibility of a less secure Samba setup. (Alternately, TKL could always instruct users to comment out/uncomment some lines "edit the config file" [as Webmin at least has a button to do that]... but then that defeats the point of having a GUI...)

Some background reading on share level security and passwordless guest access:

• Old (outdated) Samba Docs on security levels
• Samba Security levels overview
• Samba FAQ on the recommended minimal parameters for a passwordless guest share

Anyway, I would suggest that the TKL team look at this and either fix it or document it as an exception from the permissible GUI behavior. Of course I've tested this smb.conf and it works, but you should retest and confirm. Finally, since this would be a change to common, in might be worth considering whether it would positively or negatively affect other TKL tools (i.e it might be good for Media Server but not good for others).

Other than the man page clarification, I don't think this behavior is [likely to be] a Samba mailing list issue.

Thanks for your help!

Thanks for testing and sharing the results. Thanks too for opening the pull request. As you have probably noticed, there has been a little discussion there. I'm awaiting final word from one more colleague before I take any final action on that (I reckon we'll push ahead with your PR, but I just want to wait and see).

Thanks again.

Just tested in TKL:

restrict anonymous = 1

creates the same problem as restrict anonymous = 2, while

restrict anonymous = 0

does allow the [shares] parameter guest ok = yes to grant public access, as we might expect.