HOWTO: Samba and the NSLU2: Remote Drives in GNU/Linux

Yesterday’s post seemed a bit garbled to me. I wanted to work on a hastier posting style, but then see what happens? I make even less sense than usual. I’d like to set down this latest migration adventure for posterity. I’d be happy if it helps even one person in the future. This post is mostly for my own memory and those random Internet searchers looking for similar information. Expect more hasty incoherence to follow. Hasty and *extended* incoherence. Read on at your own risk. You’ve been warned.

I’ve talked about how backing data up is an obsessively crucial part of my computer usage, and mentioned that I picked up the awesome Linksys Network Storage Link for my online backups. I’ve been using it with Windows for several months now. I was aware that it is hackable, but wasn’t looking to get in to that right away.

The Slug

My first use of the NSLU2 from a GNU system was to FTP files my wife was working on in Fedora to the slug and from there copy them to my Windows box so I could burn them to CD. It’s kind of cool that the thing supports FTP out of the box, but it’s kind of clumsy for regularly moving hundreds of files over the network and I knew there had to be a better way, which I’d soon need anyway as I started using GNU more.

(Here’s your last chance above the fold to bail out on this magnum opus of minutia…)

My original post in this series talks about my first go at it. For the second round, exchanging emails with Chris Hertel helped me start understanding a few Samba basics, for example that smbfs and cifs are client-side pieces. CIFS is the newer standard that is slowly replacing smbfs. (Chris has written a whole book on cifs, so I was tapped in to an expert here! I also appreciate that he has made the book freely available. I’d buy it if I was in the market to really delve in to this stuff, but right now I’m just looking for whatever clumsy and short-sighted approach will get my backups going.)

Chris was familiar with the NSLU2, and mentioned that it runs an older version of Samba. One thing he suggested was trying to use -t smbfs instead of cifs. That hadn’t worked on Fedora but it occurred to me I didn’t try it on Ubuntu. I had tried cifs there after working out the command in Fedora (where smbfs wasn’t available, and I got super bogged down in trying to install and compile stuff to get it working — and these are the kinds of things that often make me despair of learning this stuff!). Around this time I found some web page that mentioned trying: sudo apt-get install samba smbfs. Amazingly and surprisingly, it seemed to work. I didn’t get stuck in a code compiling maze. Now when I tried the command on Ubuntu, it mounted the drive, and using the advice from Mario Stargard, it even mounted with the proper ownership with this:

mount -t smbfs -o username=admin,uid=scarpent,gid=scarpent "//192.168.1.50/DISK 1" /home/scarpent/nslu_test

This was progress. Exciting! I was happy because I intend Ubuntu to be my primary system, but I also want to keep Fedora around to broaden my horizons, so I still had some work in front of me. Looking around, it appeared that smbfs support isn’t included in the FC5 kernel. Chris had also made a comment about kernel support being needed, and I’m really trying to avoid kernel compilation entanglements for now. Even though I want to learn the nuts and bolts, I’m hoping I can go a long way without having to start rebuilding carburetors and whatnot.

Let’s Get uNSLUng

I’m also trying to build a solid foundation here. I didn’t want to make my basic backup strategy rely on client components that are going away. I might have smbfs readily available in Ubuntu today, but maybe not tomorrow. I thought about the NSLU2 and its older version of Samba. I started looking at the NSLU2-Linux web page and getting crazy thoughts. Maybe if I upgraded to Samba v3, cifs would work in Ubuntu, and maybe the ownership problem would be magically solved also.

I’m a touch bipolar on this tinkering business. I like playing around with computers, but I don’t want to spend too much time on it. And I’m not looking to acquire in-depth expertise in all areas. Playing around with hacked firmware seemed a bit on the wild side, but as I read the site, it looked like they have things pretty well tested and documented. There were some other things that looked interesting that you can do also if you “unsling” your slug, using the Unslung firmware.

I read the instructions, knowing there is some risk with firmware flashes. There are plenty of warnings on the site. I then recklessly went ahead with the flash without confirming if I’d be able to get it in to recovery mode if something went wrong. I tried the steps to verify the recovery procedure, but I was feeling impatient and brash and didn’t give it an extended effort. I figured worst case I’d be out $90. I did follow the upgrade readme pretty closely although I wasn’t clear on what I was actually doing at first. I didn’t realize that “unslinging” means you are offloading the operating system on to the usb-connected hard drive instead of running it all from flash. I did see the dire warnings against using the ipkg installer without being “unslung,” and eventually got what was going on. Kind of.

Anyway, when the system first came back up after the flash and I plugged the hard drive back in, I could see a disk, but only a few megabytes available. I read up more on the dire warnings of installing things to flash and experienced brief fear that I had done something wrong and was about to fill up my slug and “brick” it. I *had* done something wrong, or rather, I hadn’t kept with the instructions at that point and also hadn’t figured out that my ultimate goal was to get the OS running from the hard drive. I was just anxious and curious to see if I had or had not completely screwed the device up. I restarted it and could see the whole drive. Phew! Now back to the instructions to see I wasn’t supposed to be hooking up the drive yet.

I disconnected the drive and went back to telnetting in to the device and setting a root password, and then plugged the drive back in while connected, per instructions. I had the same issue with the drive being recognized funny. This was the first real quandary, since I couldn’t reboot to get it recognized like I had the first time. Fortunately, there are some good tips available:

I wanted to use disk1 to unsling. Disk1 was already formatted by the NSLU, but not recognized if plugged in after NSLU boot.
Firmware: V2.3R63. uNSLUng 6.8 beta.

The way I was able to unsling:
1)boot without disk
2)telnet to NSLU
3)attach disk (disk is powered off)
4)power on disk
5)type ‘mount -t ext3 /dev/sdb1 /mnt/tmpmnt’. => you should see your data there
6)type ‘umount /mnt/tmpmnt’
7)type ‘mount -t ext3 /dev/sdb1 /share/hdd/data’
8)type ‘mount -t ext3 /dev/sdb2 /share/hdd/conf’
9)reload the web-interface => you should see your disk there on port 1
10)proceed to unsling as described in the readme (in my case I had to type ‘/sbin/unsling disk1′)
(replace sdb* with sda* if you want to use disk2 instead of disk1)

That worked just fine for me also, and from there I got it unslung just fine. At this point I tried the cifs mount again, unrealistically hoping that it would just work now, but it didn’t. I was enjoying how this was a cool little device and that I could now telnet in to it and browse around just like any server, in this case using the BusyBox shell utilities. (The ipkg installer is really easy to use and later I installed OpenSSH to replace telnet.)

Doing the Samba on the Slug

I found the instructions for upgrading to Samba 3. Now let’s see if I can remember all that happened next… this part is already getting sketchy, and it was only just this past weekend!

The instructions are pretty good, and show you which files you need to tinker with:

/opt/etc/samba/smb.conf and /opt/etc/init.d/S80samba

I didn’t feel especially confident with what I needed to do in smb.conf. I tried some stuff and used S80samba to restart, but it looked like I had broken things because now I couldn’t connect from any of my machines: neither GNU nor Windows. I muddled around for a while, having that feeling you get when it’s all crumbling down and you’re having some regrets about the whole enterprise, but eventually I restarted the whole device and that seemed to help. I could connect from Ubuntu and Fedora, and now -t cifs worked in Ubuntu! But! Still with ownership problems. I couldn’t connect with Windows but apparently there was something cached there, and restarting WinXP solved that issue. So, breathe a sigh of relief, we’re making progress.

I discovered that my smb.conf changes had been overwritten. /opt/etc/samba/smb.conf is a symlink. It sounds like things in /opt are safe in general, and you can break the link to make your changes persist. But if the defaults work, that’s good for me.

Samba File Ownership Considerations

Now to figure out this file ownership thing. I brought up the idea of using NFS since NSLU2-Linux comes through again with a Nfs-utils package, and Chris agreed that it might be more “tuned” for Unix to Unix setups, but here he explained about how your user and group ids need to match across machines in either case. He introduced me to the concept of Samba’s unix extensions, which appeared to be turned on by default in smb.conf. I’m not sure why -t smbfs o uid=scarpent,gid=scarpent had given me the ownership I wanted when connecting that way, but I decided not to spend time investigating that. Leave the old for the new in this case.

I poked around and experimented, and the following is what I came up with. (It might sound like it was an orderly process, but it was not!)

In the NSLU2 web interface, I created a user called shareusr and a group called sharegrp. I put shareusr in sharegrp and created a share named “disk1″ (this so I could get rid of the awkward space in “DISK 1″.

Then I went in to these files:

• /opt/etc/samba/smbpasswd
• /etc/group
• /etc/passwd

and manually updated the uid and gid wherever possible so that shareusr was 2334 and sharegrp was 2445. In earlier experiments, manually changing things caused the user and group to disappear from the NSLU2 web interface config screens, but later it stayed around. Not sure what I did different.

Then I found the share on the filesystem at /share/hdd/data/disk1 and updated it with the proper ownership:

chown -R shareusr:sharegrp disk1

Now it was just a matter of creating a shareusr and sharegrp on my Ubuntu and Fedora boxes and making them have identical numerical ids, and then adding my regular user to the sharegrp group. Now when I run:

mount -t cifs -o username=shareusr //192.168.1.50/disk1 /home/scarpent/nslu_test

It works very nicely. Directories and folders are created with read and write privileges for both user and group and everything can be shared between GNU and Windows. (I had to restart WinXP again before I could use the shareusr logon there. Oh, another thing now is that when Windows starts, I get a message box about a duplicate name on the network. I should work on that but it doesn’t seem to hurt anything.)

Pretty soon I’ll also be setting up a password file and making the mount work automatically.

I haven’t restarted the slug yet, and I’m wondering if something will get overwritten when that happens, so I might have some more work to do in the future with that.

One more thing I can and should do is figure out how to use a network name instead of the IP address, but that can wait for another day. I’m able to use it well enough for now. I should mention that it’s possible I mangled the recap of things that Chris told me or that I got from the NSLU2-Linux site. Anything that sounds (or is hopelessly) wrong is almost certainly because of my poor understanding and/or communication skills. (And thanks again, Chris, for your time and advice.)

Please! Add your corrections in the comments if I’ve demonstrated a complete lack of comprehension here. Or let me know if this has been helpful at all. In either case, I’d appreciate hearing from you.

Final Thoughts

It was satisfying to find (apparent) success with all of this. It reinforces my desire to use GNU/Linux over Windows. Very empowering.

I really like what you can do with the slug. Cisco/Linksys has made a really cool little device, and NSLU2-Linux is an awesome project. I was happy to drop my $20 in the tip jar. Even though the system works fine for my purposes as is, I’m tempted to “de-underclock” it, according to their OverClockTheSlug page. The processor inside is 266MHz but my model comes with a resistor that cuts it in half to 133MHz. It looks like the simple procedure of breaking the R83 resistor with a nail clipper will double the processor speed. Sounds like fun.

Next Up

Next on the agenda is to get TrueCrypt running and figure out how to use rsync for backups. I’ve been using TrueCrypt in Windows for a while for personal and financial files and it works great. Seems quite robust. I’m looking forward to rsync — it will be way better than my current backup software and enable much better backup processes.