Today I wasted another hour or so in trying to get samba to work for one of my Windows computer so I could connect to one of my Linux computer. I knew that the installation was correct since I could log in with another computer/user that had worked for a long time. So... why would this one fail?

Two things, for of all, I could see NOTHING happening in the logs. Really wondering why the default is to log close to nothing with such a non-secure piece of software, but that's a different question. I added the following to actually get about enough logs to understand what was happening:

log level = 10 all:10

And yes, for a couple of people that might be too much. I do not recommend that you use such levels in normal operations, only to debug problems such as log in problems. In normal mode I now use this:

log level = 3 all:3

Okay! That already took me a while. Note also that log files with domain names do not enter the game until you are actually logged in so the main log file is concerned at this point.

Now, I created that new Unix user and it just did not want to work. It always said that it could not authenticate. (well, until I had the high log level, it said absolutely NOTHING, but once the log level was good enough, I could see that, finally!) Strangely enough because it said that it used the normal passwd login mechanism, but apparently that is not the case... What I had to do is create a new entry in the samba database:

smbpasswd -a <user-name>

Now, that worked. Notice the -a too, without it, if the user doesn't exist in the database yet, it fails because it views the command as an update. Note also that the -a probably fails if the user already exists.

Just in case, you have to properly setup the smb.conf file to support users. Also you may have an invalid users = ... entry, be sure that the user you're trying to log in with is not in that list. For example, to prevent root log in with samba:

invalid users = root

You may want to check out the man smb.conf page and make sure to properly setup the [homes] directory and you may also want to use the username map = ... option to support a name that's different on the Windows system than the one on your Linux system.

Windows 8 defaults changed!

I assume that this is new in Windows 8 because I did not run in that problem with Windows 7 and older versions of Windows.

I could see an error about a "dfs root" which told me pretty much zilch about what was happening:

[2013/08/31 11:02:08.070984,  3] smbd/msdfs.c:891(get_referred_path)
  get_referred_path: |username| in dfs path \servername\username is not a dfs root.

Note: DFS stands for Distributed File System.

This error is referencing a mechanism which, if I understand properly, exists since at least Windows 2000. The DFS mechanism let you create links to the actual data (softlinks in a Unix system) all in one place. This means you can enter paths such as:

\\servername\thing1
\\servername\thing2
\\servername\thing3

And thing1, thing2, and thing3 may all 3 have completely different paths on your 'servername' computer.

The DFS mechanism, however, was never used before. Since WIndows 8, it looks like it is ON by default (note that it may be a problem in samba too, but I have not changed samba's version for a while now!), even if you do not define a [dfs] area in your samba settings. The error comes from the fact that username does not exist as a DFS path.

To fix the problem, all I had to do is mark that feature as unused:

host msdfs = no

By the way, most of the people out there will tell you that the problem is the following error, which also appears in your exact same log a little after the previous error. Indeed, access is denied because the path is not matched with anything. But, I can assure you that if you get the DFS problem, the user is your last worry at this point because the user itself does not get checked at all.

2013/08/31 11:02:08.073493,  1] smbd/service.c:805(make_connection_snum)
  create_connection_session_info failed: NT_STATUS_ACCESS_DENIED

So you won't have to change your user password 20 times, or verify that the home directory is accessible (755 / drwxr-xr-x) until you fix the DFS problem.

Obviously, if you are using both: DFS and Users, I cannot help you. There seems to be problems with that concept since in my case it did not automatically switch to user mode after failing with the DFS mode.