Windows Baggage: Failing to comprehend 'network drives' in GNU/Linux

8 January 2007

Update! I figured some things out. See related posts below.

A big challenge for me in moving to GNU/Linux from Windows is not only migrating all the data that I rely on and finding free software replacements, but figuring out how to do the equivalent of all the administrative things I need to do.

When I started using Windows PCs back in 1994, I didn't have anything. No data, no maintenance requirements. My computing world was a blank slate. I started using my cousin's Gateway 486 to play Doom (in DOS), and then started going in to Windows to see what games were in there.

Gradually over time I started doing more, and in twelve years I've accumulated a lot of habits and routines. It would have been so much better to have started fresh using GNU. Now, I have a hard time starting because there's so much up front work I feel like I have to do before I can really get going, and it tends to prevent me from doing anything.

One of these hang-ups is backing up data. I gradually developed this habit until it's reached the level of compulsion where I now get the shakes if I go more than a couple of days without backing up to another machine on my home network and more than a couple of weeks without backing up to DVD. I do incremental backups every day to a networked USB drive, which stem from weekly DVD backups, which have all the changes since the most recent trip to my safe deposit box, which I visit every two to three months.

Recently I've been anxious to really get going with the move, but I don't want to start moving everything over and use GNU for more day-to-day work until I have a backup plan in place. To do that, I want to use this cool little Linksys Network Storage Link (NSLU2) device. I have one sitting in my basement attached to a 200GB drive in a USB enclosure. It wasn't much trouble to map remote drives on it from Windows, but so far I have been defeated in my efforts to use it remotely from a GNU system, of which maybe some blow-by-blow technical minutiae later, but here's the short version:

mount -t cifs -o username=admin "//192.168.1.50/DISK 1" /home/scarpent/nslu_test

Works in Fedora Core 5. The NSLU2 drive is mounted and I can see its data, but I have permissions problems. I run the command as root and it makes the owner of nslu_test and all sub-directories be "502". I get permission denied when I try:

chown scarpent:scarpent

Tried the same command (well, with sudo) from Ubuntu and get:

mount: block device //192.168.1.50/DISK 1 is write-protected, mounting read-only mount: cannot mount block device //192.168.1.50/DISK 1 read-only

Had also tried smbfs on Fedora but ran in to a big tangled mess of trying to install stuff.

And so it goes. I'm sure I'll get there, eventually, but it takes a lot of time. Each thing I try to do sends me running around in confusion trying to understand things that are far beyond my current skills. Again, I don't think it would be so bad to be a brand new computer user with GNU. You can do a lot before needing to know about what goes on under the covers. But there are several things in particular I want to do that force me in to the guts right away, where I stand in awe and trepidation at all the alien plumbing.

(6 Feb 2007) Woo hoo! I got some stuff working -->

Related Posts:

by Scott Carpenter on 8 January 2007 at 9:14 pm
permalink | comments (9) | filed under free software
tagged: the move

Comments

Could it be as simple as mounting as a read/write device?

mount -t cifs -o rw,username=admin "//192.168.1.50/DISK 1" /home/scarpent/nslu_test

Posted by James Linden on 9 January 2007 at 1:48 pm

Hi, James. Thank you for the suggestion -- tried that out on Ubuntu with the same result. (Same in Fedora also.)

Posted by Scott Carpenter on 9 January 2007 at 3:14 pm

You need to pass in uid= and gid= to set the permissions of who will own the files and directories in the mounted filesystem. You can also pass in file mode information to set up read/write information. I find the automounter to be very useful on this front since it allows regular users to mount the filesystem simply by trying to access it. Another handy trick is to put the credentials into a separate file.

For example, I might create a file in my home directory called .auth which looks like this:

username=mario password=password4me domain=happyplace

Then I could mount the filesystem like:
mount -t cifs -o credentials=/home/mario/.auth "//192.168.1.50/DISK 1" /home/scarpent/nslu_test

But then everything will be owned by root, which is not much use to me. If mario's uid=502, and gid=502, then I could do this:
mount -t cifs -o uid=mario,gid=mario,credentials=/home/mario/.auth "//192.168.1.50/DISK 1" /home/scarpent/nslu_test
which would make the files read/writable by mario and members of the group mario.

To automate all of this, put it into automount. First, make sure you have autofs installed. On Fedora systems you type:
rpm -qf /etc/auto.master
You should get an answer like
autofs-4.1.4-26
Then you need an entry in /etc/auto.master:
/mnt/smb /etc/auto.cifs
This tells the automounter that anything under /mnt/smb will be handled by it. Now the /etc/auto.cifs file should contain a line like:
nslu_test -fstype=cifs,uid=mario,gid=mario,credentials=/home/mario/.auth,file_mode=0740,dir_mode=0750 :"//192.168.1.50/DISK 1"
This all needs to be on a single line. I'm not sure how the space will work out. I usually avoid share names with spaces. Try it with and without the quotes. Finally, start the autofs daemon if it isn't already running. In Fedora, this is
service autofs start
To make it always start, type
chkconfig autofs on
Now if you browse to /mnt/smb/nslu_test, you should see your files and be able to write to the directory. After about 5 minutes of not using the filesystem, the automounter will unmount it.

Mario Stargard
Unix Administrator

Posted by Mario Stargard on 26 January 2007 at 3:40 pm

Thank you, Mario, for taking the time to give such detailed advice.

As a first step, I tried this:

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

I was able to mount it, but still with the odd permissions. I wonder if this is something specific to the Linksys device?

(That's also why there is the space in the share name -- I didn't choose that and don't know if I can change it. All I have to work with is a limited administrative web page for the NSLU2.)

I appreciate your other advice also -- this is the kind of stuff I'll want to do once I get the permissions worked out.

Posted by Scott Carpenter on 27 January 2007 at 9:15 am

Thank you, too, Mario. Had to recompile the kernel to get the drivers. Will it speak nfs or only cifs? Guess we'll find out.

Posted by Chris Smith on 31 August 2007 at 6:47 pm

Hey guys -

Ran up against this same problem very recently in SuSE 10.3 - and agree with the solution, but just make sure you dont miss ANY of the arguments:

uid,gid,username,password, and of course, lfs is a good habit to get into ;)

I noticed that for some reason, cifs is now requiring the password to be passed, on the command line, rather than asking for it after the fact.

This of course sucks, if someone is watching over your shoulder while you are having to do one of those 'real-quick-fix-hack-mounts' to test something... grrr.. maybe a bug in the new cifs driver?

anyway - just my 2c - I figured this is worthy of mention, since I personally am not using cred files, and Im sure theres gonna be a nube that runs up against it sooner than later that has no idea _about_ credential files.

Steve

Posted by Steve on 30 November 2007 at 11:21 am

Hi, Steve. Thanks for visiting and commenting.

Posted by Scott Carpenter on 1 December 2007 at 9:05 am

If you're trying to mount your Slug upon every boot, then you should just use an entry in /etc/fstab.

//192.168.1.50/slug /media/slug cifs uid=scott,gid=scott,credentials=/root/.smbcredentials

and in the /root/.smbcredentials file would be your username and password on the slug:
username=scott
password=secret
(or, you could just put them directly into the fstab line, but then everyone could see them).

However, a better way, I think is to not mount it automatically upon every boot. This way, you can control who mounts what if there is more than one person using your machine. Or, even if there isn't, you can have easy control of the mount/umount.

Here's what I do on my Ubuntu 7.10 machine.
In /etc/fstab, I have:
//192.168.1.xxx/bob /media/slug cifs user,noauto,credentials=/home/bob/.smbcredentials

That line will mount the slug to /media/slug (which, being under /media will also automatically give me a desktop icon). However, the 'noauto' attribute means it won't actually mount until I tell it to. The 'user' attribute means any user can mount it (as opposed to just root), and whatever is mounted will automatically be owned by the mounter. The credentials file is simply the basic 'username=bob', 'password=secret' stuff for logging onto the slug. And, since it's in my /home/bob directory, which is mod 700, it isn't readable by anyone else.

So, basically, upon boot, that fstab entry is read and makes everything ready to boot the slug, but leaves it in standby because of the 'noauto' attribute.

Then, I have an icon I created on my top panel that simply runs the command 'mount /media/slug' when I click it, which mounts the slug (allowed by the 'user' attribute in the fstab) and puts an drive icon on the desktop. I can later unmount it whenever I want by simply right-clicking and selecting 'unmount' (again allowed by the 'user' attribute).

Bob

Posted by Bob on 2 December 2007 at 1:08 pm

Thanks, Bob. I haven't started using fstab yet for stuff. I have some scripts to mount and unmount the two disks on the slug. The credentials file is encrypted with encfs, so I need to have that mounted first, and I want to be the one supplying the password there. This works pretty good, although I'll eventually want to monkey around with fstab.

Posted by Scott Carpenter on 3 December 2007 at 7:13 pm

You can follow any responses to this entry through the
comments feed.