This is an incredibly frustrating scenario. And you’ve fixed all the usual suspects and triple-checked everything.
We thought that this was an isolated incident, until we tried to setup and access some new PCs and notebooks for users. It only happens on desktops running Microsoft Windows 10 Creator’s Update that are completely up to date, and it occurs sporadically.
Our first big clue was that (when reviewing the SAMBA logs) the user on which login log an access attempt as the “nobody” user.
On the desktop, these are local administrative accounts. We see the server fine (no need to use the IP address hack), and are able to access public guest shares and write to these files without a problem. Damn! Changing the problem user share to guest also worked without any error. Double Damn!
Solution – use ./username
So, we tried a workaround we saw on a forum.
Precede the username with "./" as in ./myusername.
This worked like a charm! Un-double damn! On restart as well. And when we changed the user password (huh?!). And also note after successful login, and changing the user password we did not need to use “./” preceding the username anymore. Go figure!
Additional Solution – use servername/username
This also works.
We generally use the options below, and ALWAYS set devices up with a local account, and with a password.
And if you’re stuck, just delete the account in user accounts and SAMBA and start again.