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:
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.)
Best Answer
I believe I have solved the problem. In Ubuntu 12.04, in Nautilus there are two ways to connect to the remote DiskStation NAS. One preserves modification times, one does not.
In the menu on the left-hand side of a Nautilus window, the Browse Network... button eventually leads to an AFP (Apple Filing Protocol) connection to the DiskStation, through which neither Nautilus nor
cp -p
copies preserve modification time. I tried disabling Apple support in the DiskStation, but in that mode the DiskStation wasn't even visible in Browse Network.In Nautilus's File menu there is a Connect to Server... option that offers a host of protocols. I chose Windows, entered my credentials, and connected without trouble. In this mode, modification times are preserved, so I was able to re-copy my photos and have their dates preserved.
Thank you Sergey and david6 for your suggestions. Hopefully people will find this information valuable.