Mounting a Windows Shared Folder

Over the past year or so I've used several methods to transfer file between my wife's laptop (running Win XP Home) and my Debian box. I have several requirements of any such method:

1. my wife's laptop is not always connected
2. two way file transfers
   
3. non-English characters in file names
4. no crashes or stalls, no transfer errors
5. usable in a script
6. bulk file transfers
7. large files
8. one-time or automatic setup
   

While these seem rather obvious, it took quite a while before I converged on the right approach.

The first step is to share a folder on the Windows PC.

The next step is connect to that shared folder from the Linux PC:

I started out using the "Places->Connect to Server..." menu item on the Gnome panel. It's really easy: select "Windows share" in the Service type drop menu, and type in the relevant connection information (server, share, folder, etc.). This worked rather well as long as I was using nautilus for my file transfers. I couldn't figure out at the time how to access the remote files via a script with regular shell commands (e.g. cp, rm, mv).

I just recently learned that I was actually using Gnome VFS, and that files may be copied at the command line with the gnomevfs-copy utility, using the same file URI's that nautilus uses (they start with smb://).

Still, I wanted something that's not tied to Gnome, since I have plans to replace it with something else (I'll have more to say about that in the near future).

For a short while I used scp (secure copy) and sshfs (ssh user-space file system), but this method has several drawbacks: for starters I needed to setup an SSH server on my wife's laptop (available for free as part of Cygwin). It isn't straight forward.

There are other problems:

• I can't access my wife's documents folder when I connect with my own username, even though it is shared
• Filenames must be in English (I couldn't figure out how to configure this)
• sshfs tends to stall in mid transfer on my setup, I didn't investigate why.
  

The next attempt was to mount the shared folders manually using smbfs (which is the method used at my workplace). I added the following line to /etc/fstab:

//10.0.0.4/C /mnt/windows/C smbfs uid=<username>,gid=<username>,username=guest,guest,codepage=<codepage>,iocharset=utf8 0 0

Notes:

• my wife's machine has the local address 10.0.0.4
  
• it has the whole C drive shared
• I created the directory /mnt/windows/C to be used as the mount point
  
• you should replace the text in red with your own stuff
  
• the shared folder is treated here as if it is always available - I tried to add the noauto option but then the codepage and iocharset settings were ignored (probably due to a bug in smbmount).
  

Last week I got fed up with this and searched Google for smbfs - the first link I got pointed me to CIFS VFS -Advanced Common Internet File System for Linux. A few minutes later I tried the following line in /etc/fstab:

//10.0.0.4/C /mnt/windows/C cifs noauto,noexec,nosuid,nodev,uid=<username>,gid=<username>,username=guest,guest,iocharset=utf8 0 0

And it worked just fine - it meets all of my requirements!

One last note: an issue that seems to be a FAQ is how to mount a folder like "My Documents" that's shared on the windows machine? - the problem is that the space messes up /etc/fstab. The solution is to use the octal code for the space character \040, as follows:

//10.0.0.4/My\040Documents /mnt/windows/My\040Documents cifs noauto,noexec,nosuid,nodev,uid=<username>,gid=<username>,username=guest,guest,iocharset=utf8 0 0

Happy sharing!

Mount Gigabyte - Update

As part of my daily system update, I've upgraded udev to version 0.114-2. I usually take the time to go over the change logs of updated packages, but I haven't done it this time. I probably should have.

I discovered that the disk id format has changed, i.e. the entries in /dev/disk/by-id have changed. This meant that my /etc/fstab settings for my external USB disk, stopped working. The device name that was used to refer to the disk did not exist anymore.

My first reaction was to use a different method of referencing that drive (e.g. /dev/disk/by-uuid), but I figured I really should handle it the udev way:

1. use the following to detect the disk serial number (attached as /dev/sda1):
   
   udevinfo -a -p /sys/block/sda | grep serial
   
   
2. add a specific udev rule, in /etc/udev/local.rules
   
   KERNEL=="sd?1", ATTRS{serial}=="DEF1078555F6", SYMLINK+="gigapod"
   
   (this adds a symbolic link /dev/gigapod that points to the disk's first partition).
3. create a symbolic link in /etc/udev/rules.d/
   
   ln -sf ../local.rules z99_local.rules
   
   
4. modify the mount point specification in /etc/fstab as follows
   
   /dev/gigapod /mnt/gigapod vfat users,rw,noexec,nosuid,nodev,shortname=mixed,uid=bacula,gid=bacula,umask=000,iocharset=utf8,noauto 0 0
   
   
5. unmount and disconnect the USB disk
6. restart udev:
   
   /etc/init.d/udev restart
   
   
7. connect the USB disk

This way the disk is correctly mounted during the boot process, and there's no need to mount the disk in /etc/init.d/bootmisc.sh. Furthermore, Gnome seems to like it better this way (it was creating two disk icons on the desktop, one named gigapod and the other named backup60g which is the disk label - I now get only the latter).

Total control. Brrr.