How can I diagnose a NAS SMB login failure?

Question

I have a NAS enclosure (Noontec N5) that I can only interact with via a web interface (ie. no ssh). This allows me to expose the SMB service and to add users, with or without a password.

I can log in anonymously eg. with smbclient -L 10.1.0.25 -UGuest and no password:

~ • smbclient -L 10.1.0.25 -Uguest
Enter guest's password: 
Anonymous login successful
Domain=[R] OS=[R] Server=[R]

    Sharename       Type      Comment
    ---------       ----      -------
    PUBLIC          Disk      
    IPC$            IPC       
Anonymous login successful
Domain=[R] OS=[R] Server=[R]

    Server               Comment
    ---------            -------

    Workgroup            Master
    ---------            -------

I can't login with a password though:

~ • smbclient -L 10.1.0.25 -Ujason
Enter jason's password: 
session setup failed: NT_STATUS_LOGON_FAILURE

This same username works if I remove the password and log in without it (same as the "guest" login).

How can I diagnose this further, or fix it?

Update: workgroup information

The workgroup used for the device is SUNNYDALE:

~ • nmblookup -A 10.1.0.25 | grep GROUP 
    SUNNYDALE       <00> - <GROUP> B <ACTIVE> 

Adding this to the smbclient command doesn't help (it's now also in /etc/samba/smb.conf):

~ • smbclient -L 10.1.0.25 -W SUNNYDALE -U jason
Enter jason's password: 
session setup failed: NT_STATUS_LOGON_FAILURE

Update: other OSs

I found an OS X and Windows XP machine to test with, and they can both connect just fine. It appears to be some magic that smbclient does not know about (which doesn't discount the possibility that it's not in the official SMB protocol).

Update: mount.cifs

I also tried using mount.cifs, with every different kind of sec= option and vers= option listed in the man page, to no success.

Update: wireshark

I used Wireshark to capture packets between a Windows XP test VM and the NAS. It looks like XP repeatedly tries various combinations of domain names and security protocols until something works. The final (successful) attempt appears to use SMB for the domain name and NTLMSSP for authentication.

Trying these settings with smbclient and mount.cifs did not work, however.

Solution 1

Since the question is about diagnostics, rather than the eventual solution, I'll describe the things I tried that got me closer to the solution (the updates within the question summarise most of it).

When reading the command output below, note that my NAS is called giles and the domain name is SUNNYDALE. My local username, and that on the box is jason. I set a test password of abcd for this.

Spoiler: it was the authentication method.

The problem was that the NAS drive only seems to work when NTLM authentication is used from Ubuntu; most utilities use NTLMv2 by default or some variant thereof. I was stymied by the fact that the initial tools I was using did not let me control this.

Keep the box awake

Most NAS enclosures put the drive to sleep after a period of inactivity. Normally this is a good thing, but during diagnostics it can cause spurious errors with name resolution or authentication depending on the tools used.

Disable the sleep-when-idle feature while you're debugging, or keep the web interface open in a browser and periodically refresh it to make sure it's up. Remember to re-enable it when you're done!

Make sure you can resolve it

First make sure you can resolve the NAS. Use nmblookup:

~ • nmblookup giles
192.168.1.114 giles<00>

If you're not seeing it, you might need to install the libnss-winbind package (ie. with sudo apt-get install libnss-winbind) and edit /etc/nsswitch.conf. Look for a line beginning with hosts: and place wins somewhere:

hosts:          files mdns4_minimal [NOTFOUND=return] dns wins mdns4

(Please note I'm no expert on these settings; record what the line was before in case you run in to trouble later.)

Use mount.cifs, not smbclient

I found that smbclient did not catch my problem because it does not allow you to fine-tune the authentication settings. The mount.cifs utility does, however. There are a few other details it gives you more control over, eg. the SMB protocol version used. This terminal session shows how you can try different domains and authentication methods:

~ • mkdir temp
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE,sec=ntlmv2
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SUNNYDALE,sec=ntlm
~ •

(That last command was successful.)

Note that you might get some spurious failures from mount.cifs though, eg.:

~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SMB
mount error: could not resolve address for giles: Unknown error
~ • sudo mount.cifs //giles/jason ./temp -o username=jason,password=abcd,domain=SMB
mount error(13): Permission denied
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Sometimes I even got an authentication error on the first try but not the next. Try each command two or three times to be sure.

Override smb.conf settings/tool defaults

Be careful when debugging SMB problems that you're not relying on the defaults in either /etc/samba/smb.conf or mount.cifs (or whatever tool you're using). In particular, the workgroup (line starting workgroup =) and the authentication method (client ntlm auth = ... for example, with multiple lines for different protocols).

Note that in the mount.cifs terminal session above, I always specify the domain while changing the authentication method. Be scientific! Change one and only one thing each time. If it gets tedious, write a script!

Try different workgroups

As Ben Grimm points out, sometimes these boxes ignore the workgroup you give them. Try one of the following:

• WORKGROUP
• SMB

Find a Windows or OS X machine

This is a basic sanity check: if you can connect from a Windows or Mac machine, it should at least be possible (even if difficult) to connect from Ubuntu. If you can't connect from any other machine, go back to the start and try to configure things until you can.

In my case I didn't have a non-Linux machine to try with at first. Eventually I found an old XP VM (it was a backup of a machine from years ago). I realised that I could connect to the NAS just fine from it! This led me to my next tactic…

Wireshark

Wireshark is a program that inspects and dumps packets going through an interface on your computer. Once I realised that my XP VM could connect, it became a matter of figuring out what that machine was doing that my Ubuntu machine was not.

Wireshark only monitors interfaces on the computer it's run on. This means that you must run it on a machine that sits in between your test machines and the NAS box. I'm not going to give a full tutorial on routing etc. here, but it worked for me because I ran it on the machine hosting the XP VM, so all the packets were going through eth0 as far as Wireshark was concerned.

In my case, the XP VM had IP 192.168.1.111 and the NAS had IP 192.168.1.114. So the capture filter I used in Wireshark was:

(host 192.168.1.111) and (host 192.168.1.114)

Then I:

• booted the XP VM
• started the capture
• in the XP VM I launched Explorer, entered \\giles\jason and hit enter
• entered my credentials and the domain
• once the share was opened, I switched back to Wireshark and stopped the capture.

At this point, I looked through the packets by using Edit > Find packet... and selecting the "by string" option. I just searched for my username and looked for the first successful authentication attempt. You can see which are unsuccessful by looking for STATUS_LOGON_FAILURE a few packets later.

What surprised me was the sheer number of attempts that XP was performing. It used the given username and domain name, sometimes it used WORKGROUP or SMB or even the client name as the domain, and it tried multiple authentication methods.

Funnily enough, I never even identified the successful attempt! This was the point at which I realised smbclient was not going to help, and went back to mount.cifs and used it much more scientifically.

A note about NTLM and Nautilus/GVFS

Finally, after figuring out what the problem was and successfully accessing the share via mount.cifs, I still couldn't get Nautilus to connect. The problem here is the Nautilus uses GVFS to mount SMB shares, and GVFS uses NTLMv2 by default.

You can change this system-wide by editing /etc/samba/smb.conf and adding:

   client ntlm auth = yes
   client ntlmv2 auth = no

I added this just below the workgroup = ... setting. However, this will force the change for all SMB shares GVFS tried to mount, which might make other shares inaccessible, so beware.

(For some reason mount.cifs complains about that first line, but testparm doesn't. Perhaps it can be removed, but I'm not game to try.)

Solution 2

With these boxes it seems that forcing the workgroup is necessary:

smbclient -L 10.1.0.25 -W WORKGROUP -U jason

You can verify the workgroup of the box by running:

$ nmblookup -A 10.1.0.25 | grep GROUP 
    ..__MSBROWSE__. <01> - <GROUP> B <ACTIVE>
    WORKGROUP       <00> - <GROUP> B <ACTIVE>
    WORKGROUP       <1e> - <GROUP> B <ACTIVE>

Comments

[Fabby]

I've looked around the web for manuals, firmware, ... and I'm very sorry to say, but the enclosure you have is not a great product. So no answer, just a comment: If you have an Ubuntu PC, take the drive out of the enclosure, put it in the PC and share it from there. If you have no PC, buy another enclosure... :(

[detly]

@Fabby - yeah, I'm trying to get some information out of the manufacturer about this, but it looks a lot like it doesn't really support SMB properly. I asked here because in my experience, sometimes there are "magic" packages you can install to get extra SMB functionality on Ubuntu desktop systems. The trouble is, there's no other single bay NAS out there, at least not that's ridiculously over-featured, over-priced or over-sized. And I can't just plug it into an Ubuntu machine, because I need USB access. Crap.

[detly]

If I plug it into a USB machine, the other device that requires USB access won't be able to use it. Hence my need for a (small form factor) NAS.

[Fabby]

No you misunderstand: I'm talking about adding a USB peripheral controller PCI card into the PC. You then plug the laptop into that particular port on the back of the server and the entire PC then becomes just a rather large USB drive...

[detly]

Ohhhh. A nice idea, but it won't work with the machines I have. Maybe single bay NAS enclosures just aren't a thing that anyone wants any more.

[Fabby]

Let us continue this discussion in chat.

[detly]

Mods: please ignore my previous flag on this, it turns out is is a solvable problem and might contain a few transferable lessons for others trying something similar!

[detly]

This doesn't seem to help. I've added the details to my question.

[Ben Grimm]

Even though it replied with SUNNYDALE, did you happen to try with WORKGROUP?

[detly]

Just tried that too, no luck :/

[detly]

Even though I accepted my own answer, you get the bounty because this got me going in the right direction.

[Ben Grimm]

Thanks! I only wish I could have helped more, but your perseverance clearly paid off.

[detly]

Hah, that's okay! It made me realise that where SMB is concerned, there's a lot more stuff going on under the hood than the simpler tools expose.