I just resolved a problem which has been an annoyance for two years. I’m posting the details as robobait in the hopes it will help others.

Our family network includes a Samba file server hosted on an NSLU2 server appliance by Linksys (now a part of Cisco). A long time ago we changed to the Unslung open firmware for the NSLU2 (or “Slug”, as we call it).    It’s a wonderful combination, powered by a rich assortment of free software created by many volunteers. I appreciate their efforts.

But two years ago, I moved my personal computing from a laptop running Mac OS X 10.3 to one running Mac OS X 10.5. On the new 10.5 laptop, I noticed that the NSLU2 failed to respect file modification times. That is, if I had a file created on Dec 1, 2007 on my laptop, and I dragged it to a Samba volume hosted on the NSLU2, then the time stamp on the copied file was changed to the present time. The Dec 1, 2007 modtime was lost. Similarly, if I used touch -t from the Mac OS X command line to change the timestamp on a file hosted on the NSLU2 Samba volume, the operation failed. If I tried  sudo touch -t, that succeeded, just until another client viewed the file — at which point the timestamp snapped to the present again. However, if I copied a file resident on the NSLU2 Samba volume to another location on the volume, the timestamp was preserved.

This problem was very annoying. It didn’t stop me from archiving recent files on the NSLU2, since the timestamp was still correct to within a few days or weeks. But it did stop me from archiving files from my laptop to the NSLU2 Samba volume. I like having accurate timestamps and other metadata on my archived files; I find it useful years later when understanding my archives.  This annoyance persisted for two years.

During the recent holidays, I took a couple of days to read through the Samba documentation and the Unslung (NSLU2-Linux.org) page on Samba. I tried this and that. Finally, I solved the problem.

It turns out that my NSLU2 was running Samba 3.0.11. I think this was the version which came with the NSLU2.  I upgraded Samba to the current version in ipkg, which is 3.2.15-1 at the moment. After this, my Mac OS X system preserved modtimes when copying files to the NSLU2‘s share. Also, the touch -t command now succeeded. Hooray!

I speculate that Mac OS X 10.3’s CIFS (SMB) client code used the CIFS protocol in some way which Samba 3.0 could accept and respect modtimes. However, Mac OS X 10.5 has different CIFS client code, which might use the CIFS protocol differently. Perhaps Samba 3.0 couldn’t respect modtimes with this usage of the protocol, but Samba 3.2 could.

I had suspected that the problem might be related to my Mac OS X user id using a particular integer uid. In Samba and in Windows networking security, the RID (“relative identifier”) with that same value is well-known to have a specific meaning. I thought there might be a conflict.  It turns out there probably wasn’t. Firstly, the Samba uids were safely out of the well-known range, and didn’t match the Mac OS X uids anyhow. Secondly, the Samba ownership is entirely a function of which user id and password one uses to connect to the Samba server, not what user ID one uses on a client computer.

While I was at it, I was able to configure Samba to interpret the octets of its directory and file names as UTF-8, and to offer UTF-8 file names to its clients. This meant that I could safely use non-ASCII file names on this server.  Before the change, I was limited to ASCII file names from my Mac OS X client.

There were many details I learned in the course of this work which might benefit other NSLU2 users.  I have tried to write the most important of them in the nslu2-linux.org pages on Samba, Nano, etc. This is a small repayment of the value I’ve received from all the others who wrote those pages before me.