The usual fix for this is to re-export or restart nfs services from the server side. You could try unmount -f to force the mount point to unmount or reboot the client. It gets harder when multiple users are online. If someone has a home directory or a remote shell open using a directory under the nfs mount root, good luck fixing it on the fly. The worst situation is where two NFS file systems are mounted in a parent-child relationship.

f you’re mounting a file system via custom udev rules, hal does not populate /media/.hal-mtab. When a desktop user attempts to unmount the file system, hal complains that it doesn’t know anything about that file system and gives you a friendly message about console users that may have mounted it.

In udev rules, the %k, %b, %n variables are nice and all, but you can also use the variables you’re comparing and setting such as ID_FS_TYPE, KERNEL, SUBSYSTEM, PHYSDEVPATH, etc. When you run a command in a udev rule, there’s nothing stopping you from calling a shell and executing a few commands without actually calling a standalone script to do the dirty work. If you write out the array of environment variables from inside an external program, you can get a better understanding of just which part of the device discovery is matching your rule and getting processed.

This lets you access your Linux home directory and local DVD drive from Windows without having to set up additional cifs/nfs mounts. My home directory is an NFS mount from another server, so you should be able to access *any* file system that is available on your Linux side.

If you want to store a mix of encrypted and unencrypted files under the same area, choose plaintext passthrough, otherwise choose the default, no. I suggest an all or nothing approach, as it can get confusing as to which files are encrypted especially when they’re binary! (With ascii text files you can just cat a file and tell if it’s encrypted or not.)

Look in the directory /dev/disk/by-id to see how your attached storage devices are mapped in dev. If they are not already identified by UUID or Label, they will just get the next available letter in the alphabet. sda, sdb, then sdc, etc. The reason why you want to see them “by-id” is because if you plug in multiple devices in a different order one day, you may find what was “sdb3″ yesterday is “sdc3″ today. Look up the Universally Unique Identifier using the blkid command (part of e2fsprogs) The identifiers are generated when partitions are created. Non partitioned devices will not have these identifiers. Use of UUIDs are preferred over Labels since Labels are not unique.