bizarre symptoms using guest account on CIFS share

[raymod2]

I posted about this in the Help & Support forum but I was ignored for the last two weeks. I also filed a bug report (https://bugs.freenas.org/issues/3396) but that has been ignored as well. I was hoping someone here could reproduce this and/or comment about whether there is a plan to fix it since it impacts a very common use case for FreeNAS.

In short, when I create a CIFS share and enable anonymous access via the guest account I experience strange permission failures when accessing the share from a remote machine. Files can be created but not renamed or deleted. This causes applications to leave behind temporary files (such as gvim which creates files named "4913").

If I go into the guest account settings and uncheck "Disable password login" (followed by a reboot) then the permission problems disappear and instead I get the following errors in the console:

Nov 9 12:54:48 freenas smdb[3282]: [2013/11/09 12:54:48.237419, 0] ../libcli/auth/ntlm_check.c:54(smb_pwd_check_ntlmv1)
Nov 9 12:54:48 freenas smdb[3282]: smb_pwd_check_ntlmv1: incorrect password length (74)
Nov 9 12:54:48 freenas smdb[3282]: [2013/11/09 12:54:48.237938, 0] ../libcli/auth/ntlm_check.c:54(smb_pwd_check_ntlmv1)
Nov 9 12:54:48 freenas smdb[3282]: smb_pwd_check_ntlmv1: incorrect password length (74)

The bug report has more information and shows the steps needed to reproduce this issue (which I have done several times after starting with a fresh installation of FreeNAS). I never had a problem with FreeNAS-8.0.2-RELEASE which I used for two years before recently upgrading to FreeNAS-9.1.1-RELEASE.

 

[raymod2]

Setting/unsetting "disable password login" is the result of hours of experimentation trying to solve this issue. It should have no relevance to my issue. I mention it because it appears to be a clue.

 

[cyberjock]

It's not a clue(other than you are desperate and trying things you probably shouldn't).

The disable password login should be checked. It's in the CIFS shares link you provided in the other thread. Notice that it says to "disable logins box" and doesn't say to enter a password. Since you didn't enter a password it is supposed to fail to let you login since you forced the login(by unchecking the box) to require a password but you didn't add one. Otherwise by unchecking that box you could, in theory, have a passwordless account that lets you authenticate with it. Clearly that's probably not the intent of 99.99999% of situations. So by default when you choose to uncheck that box if you have no password it throws the error you see. Completely 100% normal.

If you want to leave that box checked then you must enter a password for the guest. But, that defeats the purpose of the guest account since you'll be queried to enter a password. Guest accounts shouldn't normally be any real authentication in any form.

 

[raymod2]

Please read the bug report again. Neither setting of "disable password login" works correctly. Checking the option causes strange permission errors and unchecking the option causes constant error messages to be printed in the console. That is not normal and it is not the behavior exhibited by FreeNAS-8.0.2-RELEASE. This is a regression.

 

[Dusan]

I think this might help: switch the Authentication Model from Anonymous to Local user.

 

[raymod2]

@Dusan - Thank you! Your suggestion worked. I changed "Authentication Model" from "Anonymous" to "Local User" and I no longer see any of the symptoms I described above. The permission problems are gone as well as the console errors. I can now leave "Disable password login" checked or unchecked (depending on whether I want to access ssh using that account). Can you explain why this resolved the issue? I'm a little surprised because I was definitely using "Anonymous" with FreeNAS-8.0.2-RELEASE. Should I close the bug report?

 

[Dusan]

I checked what does the Anonymous setting actually do. It sets this in smb.conf (${guest} is the guest account you selected):

Code:

security = share
force user = ${guest}
force group = ${guest}
passdb backend = tdbsam:/var/etc/private/passdb.tdb

The smb.conf documentation contains this warning regarding security = share: "This option is deprecated as it is incompatible with SMB2". You can also notice that the code assumes that there exists a group with the same name as the guest user. This is not true in your case.
I use a mix of guest & protected shares with the Local user mode and it works nicely, so I suggested you try the same.