Skip to main content
Welcome guest. | Register | Login | Post

Using external file devices in Linux: Climbing the "mount" command

In my four years of using Linux, getting USB drives, memory cards, CD-ROMs, and Windows shares in a state where I could actually use them has been one of my most frustrating problems. Printing, by comparison, has been far easier. I was frustrated even that I had to use the "mount" command, not to mention all the issues with getting it to work the way I wanted it to. In my four years of using Linux, it has gotten a lot better about automatically detecting and mounting devices; in particular, I almost never have to mount hard drives or CD-ROMs manually any more. Other devices, however, remain problematic. You may never have to use the mount command in Linux. You may also win the lottery jackpot; I wouldn't bet on either. This article is intended to help new users save a lot of the time and trouble that I have gone through.

(Note: I am not a Linux expert. I have learned a lot, but I'm sure there is plenty I don't know. This article is based on my experience, not on a detailed technical knowledge of how Linux works behind the scenes. Also, I have been using Ubuntu almost exclusively for about two years now, and although most of this should apply to any distribution, there is a possibility that some things will be different.)

Syntax of the "mount" command

We're going to delve into the command line, which is probably enough to discourage some people. I certainly avoided it when I started using Linux, but sometimes there is no good way around it. The good news is that the mount command is not all that difficult in principle. In order for you to use files on a given device, you have to tell Linux three things. First, you have to tell it which device you want it to read—a hard drive, USB drive, etc. Second, you have to tell it the directory that you want to assign to the device. Unlike in Windows, each device does not get a separate drive letter, like C: or D:. Under Linux, the device just shows up in a directory somewhere in your file hierarchy. Third, you have to tell Linux what filesystem the device uses.

The syntax for the mount command, then, is this:

mount -t [type] [device] [directory]

You usually have to be root to run this command, or else preface it with "sudo."

The last parameter, directory, is the easiest part. You simply have to create a directory somewhere in your file system where the files will show up. For removable media such as CD-ROMs and floppy drives, many distributions will put these directories under /mnt or /media. For example, Ubuntu has a directory for the CD-ROM at /media/cdrom0 and for the floppy at /media/floppy0. This is a convenient place to put things so you can easily find devices that have been automatically mounted, but you can put the directory anywhere. For example, you may want to create a directory under your home directory, such as /home/[username]/cdrom. (I'm assuming that you're the only person using your computer; if several people use it, you wouldn't want to mount a drive under your home directory unless you had some reason to keep other people from seeing it.)

The first parameter, type, refers to the filesystem used by the device. There are different ways of storing files on a device, and Linux needs to know which one the device is using before it can read it. Although this sounds intimidating, it's usually pretty simple. The external devices that we're dealing with will use one of the following three filesystems:

  • iso9660: cdrom drives
  • smbfs: Windows share
  • vfat: floppy disk, USB drive, memory card

There are many more types of filesystems, but most of them are used by Linux to store files on the hard drive (as in other cases, Linux gives you a lot of choices). There is a nice, in-depth discussion of filesystems on on Wikipedia if you want to know more—but you probably don't need to know any of that information for common uses. There is also an "autofs" option, which I gather is supposed to detect the filesystem for you automatically, but I've never gotten it to work (nor have I had much need for it).

The second parameter of the mount command, "device", is the one that has caused me the most trouble. Linux recognizes devices as files under the /dev directory. Most of them are assigned perfectly logical names. For example, if you have an IDE hard drive, it will probably be /dev/hda. A second hard drive would be /dev/hdb, and so on through the alphabet. If your hard drive is partitioned, as it probably is if you use Linux, each partition is a separate device. The first partition would be /dev/hda1, the second /dev/hda2, and so on.

That's relatively easy, because you usually only have one or two hard drives. The same also goes for floppy or CD-ROM drives. The first floppy drive is usually /dev/fd0. CD-ROM drives using IDE (as mine does) are just like hard drives, so if you have one hard drive at /dev/hda, your first CD-ROM will be /dev/hdb. (Since the CD-ROM is not partitioned, you don't have to worry about a number; it would not be /dev/hdb1, for example.)

Okay, but what if you plug in a USB drive? I've got four USB ports on my computer, plus a four-port USB hub plugged into one of them. USB devices are at /dev/sd*, but which one? You can actually test for the existence of a device by using the command

cat /dev/sda1

or whatever device you want to check. If there is a device at that address, your screen will quickly fill up with garbage; if not, you will get a notice that there is no such file or directory. Checking all possible devices this way would be tedious, however.

That's where I was stuck until a few months ago, when I learned a valuable tip. When you plug in a device, Linux knows that it is there and immediately assigns it to a file in the /dev directory. Even though it is not mounted, therefore, the system knows it's there — you just have to figure out where. The answer is in the /var/log/messages file, or in the "dmesg" command. I'm not sure what the difference between them is; both seem to work for me, and to have approximately the same information. You'll want to look at the end of the output, since, if you just plugged in your device, it will be the last thing in there. To do that, you can use the "tail" command:


tail /var/log/messages

or


dmesg | tail

This will only give you the last 10 lines of a file, by default. I often use the "less" command instead (same as above, but substitute "less" for "tail"). You can use capital G to jump to the end of the file, and then page backward by pressing "b" as often as you need to.

Let's take the example of a secure digital (SD) card, which I just plugged into my card reader. The last few lines from /var/log/messages are:


Mar 20 14:57:50 localhost kernel: [17202504.352000] SCSI device sdc: 1960449 512-byte hdwr sectors (1004 MB)

Mar 20 14:57:50 localhost kernel: [17202504.352000] sdc: Write Protect is off

Mar 20 14:57:50 localhost kernel: [17202504.352000] SCSI device sdc: 1960449 512-byte hdwr sectors (1004 MB)

Mar 20 14:57:50 localhost kernel: [17202504.356000] sdc: Write Protect is off

Mar 20 14:57:50 localhost kernel: [17202504.356000] sdc: sdc1

Mar 20 14:57:50 localhost kernel: [17202504.376000] printk: 144 messages suppressed.

You can see that the device I plugged in was a SCSI device, which tells me that the device name will begin "sd". I don't really need to know that, however, because a few lines later I get the exact device: sdc1. All devices are in the /dev directory, so the full path to my memory card is /dev/sdc1.

We also know that memory cards use a vfat filesystem (see above). I'm going to choose to mount the memory card at /media/sdcard. Finally, we have enough to use the mount command:


mount -t vfat /dev/sdc1 /media/sdcard

Gotchas

How can I be sure that the mount worked? One way is to look at the /etc/mtab file, which is a list of all currently-mounted filesystems. The information in this file is the same as that passed to the mount command, although, for some reason, in a different order: device, directory, type. If your device is mounted, you should see a line like the following, probably at the end:


/dev/sdc1 /media/sdcard vfat ro 0 0

(I have no idea what the numbers at the end mean, and I've never had a need to change them.) I usually navigate to the directory where the device was just mounted (using either the command line or a GUI tool like Nautilus) to make sure something is in there. However, this is not a good way to check if the device is mounted, unless you already know what is on the device. For one thing, if the device is empty, you'll get the same empty directory listing that you would if the mount command failed. Second, the directory that you are using to mount the filesystem is still a usable directory, even if the mount command failed. That's right, you can have two sets of data in the same directory: one from the device mounted at the directory's nearest parent (for example, your hard drive), and a second from the removable device that you are mounting! The good news is that there doesn't appear to be any danger of overwriting data by mounting a device onto a directory that is already being used (at least, I haven't had a problem with it). The bad news is that you could see files in a directory even when your device is not mounted. The best practice is always to mount devices to an empty directory (create one if you need to), and always check your mount command by looking in /etc/mtab if you have any doubts about whether it worked.

Happily, our device shows up in /etc/mtab, so everything's fine now, right? Maybe. At least, if we got the contents of the directory, we know we can read files from the disk; but can we write to it? We didn't specify that we were mounting the memory card so we could write to it, so it may have been mounted read-only. We can correct that by passing an option to the mount command. But before we do can mount our device with the correct options, we have to unmount the incorrectly mounted version. (There are ways to re-mount a device with different options, but we won't go into that here.)

The command to unmount is, thankfully, simple:


umount [directory | device]

That is, you can specify the directory or the device that you want to unmount, and you don't need to add in any arguments. Notice that it is "umount" (no "n" after the "u") instead of "unmount". The only catch with unmounting is that nothing can be accessing the device at the time. Therefore, if you have Konqueror or some other file manager open to the mounted directory, or if the current working directory in one of your command shells is the mounted directory, umount will fail. Sometimes a process will be using a file from a mounted device in the background and you won't know what it is. In that case, you can try passing the "-l" option to umount to do a "lazy" unmount. Of coure, with removable media such as a USB drive or memory card, you can always just pull it out — but I don't recommend it. Chances are good that if you do this, all the changes that you just made to the device will be lost. I've had this happen a number of times when I removed a device after umount failed—trust me, it is very frustating. Also, with CD-ROM drives, usually Linux will not let you eject the CD until it has been unmounted properly.

We've unmounted our device, so now let's remount it and specify that it will be "read-write." We do this by adding the "-o" argument to the end of the mount command (for "options"), and putting "rw" (for "read-write") after it:


mount -t vfat /dev/sdc1 /media/sdcard -o rw

We've done that step, but when I go to copy a file to it, I still get the error "Permission denied." Why? Well, I mounted the device read-write, but only for the owner; and since I mounted it as root, the owner of the directory is root. To explain this further, you need to understand Linux file permissions, which are beyond the scope of this article. I will simply say that the permissions that you assign to a directory are *irrelevant* to the permissions of the directory after it is mounted. It took me quite a while to figure out that the permissions are assigned *in the mount command*, and override whatever permissions you have set on the directory. You need to add an option to set the permissions you want. To allow full permission to everyone, you will add "umask=000" (those are zeroes, not the capital letter "o"s). Our command is now:


mount -t vfat /dev/sdc1 /media/sdcard -o rw,umask=000

Notice that we can add additional options by just separating them by a comma.

Windows shares

I have saved the problem of mounting Windows shares for a separate section. The protocol for sharing file information in Windows is called Samba, and the filesystem that you use for the mount command is smbfs. Actually, there is a separate mount command, "smbmount", just for Windows shares, but you don't use it. Instead, when you mount an smbfs filesystem, the mount command calls smbmount for you. For the most part, you never need to know the difference. The only time I have found it important is when I need to know the options for smbmount, which are not found on the man page for the mount command; instead, do "man smbmount".

Mounting a Windows share is pretty much like mounting any other device, with the obvious exception that the Windows computer is not connected directly to your computer, but instead you communicate with it over a network. Therefore, the "device" that you are mounting is not in the /dev directory. Instead, you will use (a) the name of the Windows computer, and (b) the directory that it is sharing. Use slashes as in the following example:


mount -t smbfs //WindowsPC/SharedFolder /MountDirectory

If you don't specify a share in exactly the format shown above, you may get an error that you have too few "\" characters in the share name. Don't let the fact that this error refers to a backslash deter you; what it actually wants is a regular Unix forward slash.

Another possible difference when using a Windows share is that you may have to log in to use it. To do this, we will simply use the options at the end of the mount command to specify a user name and password, as follows:


mount -t smbfs //Windowscomp/sharedfolder /mywindowsdir -o username=myuser,password=mypassword

There are lots of other options here, for example, passing "guest" instead of a username and password, and ways of passing the username and password more securely; but this should at least get you hooked up.

Finally, mounting a Samba share does not have the "umask" option. Instead, you can use the "fmask" and "dmask" options, which set permissions for files and directories, respectively. The trick is that this is exactly backward of how umask works: it sets the permissions that are turned on, not the permissions that are turned off. So, to allow all permissions on a share, do this:


mount -t smbfs //Windowscomp/sharedfolder /mywindowsdir -o username=myuser,password=mypassword,dmask=777,fmask=777

Dmask and fmask are available as options for other filesystems if you want to set permissions for directories and files separately, but they work like umask, so set them to 000 for full permission.

I will mention one other issue with Samba shares, because I ran into it recently and had a heck of a time finding the solution. Apparently, Samba is only set up to deal with files of up to 2GB, which is not usually a problem. Since I was trying to copy videos, however, it was an issue for me. The solution is to pass "lfs" as one of the options:


mount -t smbfs //Windowscomp/sharedfolder /mywindowsdir -o username=myuser,password=mypassword,lfs

Summary

This article has not tried to cover all aspects of the mount command. I have not dealt with filesystems on your local hard drive, mainly because most distributions mount them automatically. The principle is the same, but you have to choose the correct filesystem, and Linux can use almost all of them; you may also have a Windows partition that uses vfat or ntfs. I have not dealt with NFS shares, which is a common way of sharing files on a Unix network. Since you almost always have to set up NFS shares yourself, I figured that, if you are using them, you already know how to mount them. Again, the principle is the same, and the filesystem is nfs, but the device name takes a special form. You can find information about all of this in the man page for mount, along with many other options.

Finally, I have not dealt with getting Linux to mount your devices automatically when they are connected. To mount them automatically at boot time is actually pretty simple: you just need to add a line to /etc/fstab that matches the mount command parameters that you want to use, but in the format of the /etc/mtab file. The problem is that, for removable devices, mounting at boot time is rarely an option. There is a way to get Linux to detect when a USB device connects and to mount it automatically, but I haven't figured it out. Actually, my Ubuntu distribution (Edgy) is good enough to detect a USB drive or memory card, mount it, and open up Nautilus to the appropriate directory. Unfortunately, it mounts the device read-only, so I have to unmount it and remount it using the parameters that I want.

What I have given you, I hope, is a simple set of instructions for mounting devices that will deal with your most common problems. Unless you use a distribution that automatically mounts and unmounts devices for you, this is probably something that you will have to learn sooner or later.

If you need any help with any Free Software we're waiting to help in Nuxified forums.

Note: Many things in this article have been corrected or add to in the comments that follow.

Comments

The easiest way to see what

The easiest way to see what has been mounted is not to look at mtab, but to simply type mount without any arguments.

Fstab is not just for automatically mounting things, here's an example from my fstab:

/dev/hda2 /mnt/windows vfat user,noauto,noexec 0 0

This allows any user to mount the windows partition writable with mount /mnt/windows, but does not mount it at boot time.

Mounting "on top of" a directory that already contains something is safe, but could put you in chicken and egg situations, for example mounting something over /bin is a bad idea because that will hide the umount command.

If you have trouble finding out which program is preventing an unmount, you can find it using lsof +D /the/directory/you/want/to/unmount. Note that this can take a while because it will look at all files in the directory and ask the kernel if any program opened them.

I wrote the article to be

 

I wrote the article to be instructional, but I've already learned several new things from your comment. Smiling I never could figure out the purpose of including an fstab line with "noauto" in it -- thanks for pointing it out.

Sincerely,
Derek

It's really easy to

 

It's really easy to identify devices when using UDev.
For USB-Devices you can never be sure if they'll always be /dev/sda or maybe sometimes become /dev/sdb (or something else) because there's another device already.
With UDev (which most distros should be using by now) you can create a rule to create a symlink like /dev/mp3stick when you plugin your MP3-stick and have the symlink also removed when the stick is unplugged.
It's fairly easy and comes in really handy, because with that you can put /dev/mp3stick in your fstab and there's no need to worry which device it actually is.

I'm sure it's easy, but a

I'm sure it's easy, but a link to a short tutorial would be nice.

I have none at hand right

 

I have none at hand right now, but I'll try to look one up or write one tonight.

Another thing:

Quote:

If you have trouble finding out which program is preventing an unmount, you can find it using lsof +D /the/directory/you/want/to/unmount. Note that this can take a while because it will look at all files in the directory and ask the kernel if any program opened them.

You can also do a lazy unmount, which means that programms currently using the data from the mounted device can still do so until they are finished, but nothing new will have access.

umount -l mountpoint

I just updated my UDev and

 

I just updated my UDev and also finally wrote a rule for my USB-stick.
When I plug it in it will create /dev/kingston and also devices for the partitions, since by default there's only 1 partition that's /dev/kingston1.

The rule is as follows:
KERNEL=="sd[a-z]*", BUS=="usb", SYSFS{serial}=="5B730189A4A9", SYMLINK="kingston%n"
You can also use other values from SysFS to identify a device, but I guess the serial should usually do.
Getting that information is a little more tricky, you'll need to plug in your device while monitoring UDev with udevmonitor
You'll see something like this:

Quote:

UEVENT[1175257651.965680] add /class/usb_device/usbdev1.13 (usb_device)

Now you can use this information to get all the info with lsusb (you can also skip the part with udevmonitor if you like, but it can help to identify the device) by calling lsusb -s 1:13 -v
You'll get a lot of information which you can use for your UDev-rule. Call lsusb again and grep for the serial if you want to use that.
For me this shows this:

Quote:

iSerial 3 5B730189A4A9

The last part, behind the 3, is the serial I'm looking for to use in my rule.

Later I'll write rules for my DVD-drives again, I'll also post and explain these.

lazy unmount

reptiler wrote:

You can also do a lazy unmount, which means that programms currently using the data from the mounted device can still do so until they are finished, but nothing new will have access.

umount -l mountpoint

Yes, but that's not very useful when you want to remove your usb stick...

Right, but it can be useful

 

Right, but it can be useful for other things.
On my EasyLFS for example, the script is supposed to unmount the partition and then reboot, but it cannot really unmount because something is still running from that partition. So the scripts calls a lazy unmount and starts the reboot. The script will end then and, before the reboot really shoots off, or at least before it's done, the device will be properly unmounted.

For the USB-stick, at least it prevents new access to the device, and processes that currently work on it can still finish (or be killed if you like).

mount iso files

 

one thing that took me a while to find out was the command for mounting ISO files,

mount -t iso9660 -o loop /isofile.iso /mount/point

I find myself using this command at least once a day.

In case you need a real

 

In case you need a real device, which I, again, need for EasyLFS, you can use losetup to assign the file to a loopback-device.

losetup -f /testlfs.img
will enable the use of the next free /dev/loop-device, which can be checked beforehand by
losetup -f
If no device has been enabled before, this of course will be /dev/loop0.

losetup -d /dev/loop0
will clear the association and the loopback-device will become unusable.
This step can be skipped and integrated into unmounting by using -d with umount.

man umount wrote:

-d In case the unmounted device was a loop device, also free this
loop device.

there is no technical

there is no technical connection between FAT (which is vfat) and floopies, USB devices or memory cards. VFAT only means DOS formatted, which happens to be most common for these examples, but I have created ext2 partitions on USB sticks, and if you get a floppy image of a linux distribution, it will definately NOT be FAT formatted

DDC - discs don't care.

 

DDC - discs don't care. They are just containers, you can even record a CD with ext2 if you like, no problem at all.

,lfs

 

WOAH! Thanks!!! I was just reading this article for the hell of it, mainly to see if there was anything I didn't already know about shares and you've answered a question I hadn't even started looking for an answer for!!

Only this morning I discovered my remote samba share gzip backup script was dieing, I ran it manually and it kept dieing at exactly 2147483647 bytes. Now I know the cause of the problem and have the solution!

dcroxton wrote:
I will mention one other issue with Samba shares, because I ran into it recently and had a heck of a time finding the solution. Apparently, Samba is only set up to deal with files of up to 2GB, which is not usually a problem. Since I was trying to copy videos, however, it was an issue for me. The solution is to pass "lfs" as one of the options:

mount -t smbfs //Windowscomp/sharedfolder /mywindowsdir -o username=myuser,password=mypassword,lfs

Quote: If you have trouble

 
Quote:

If you have trouble finding out which program is preventing an unmount, you can find it using lsof +D /the/directory/you/want/to/unmount. Note that this can take a while because it will look at all files in the directory and ask the kernel if any program opened them.

Actually, there is another command built just for the purpose of finding out who is currently using a perticualr file or filesystem (and thus preventing it from being unmounted)
That command is "fuser" e.g.
fuser /mnt/disk/mydir/myfile
To check which process is using the file "myfile" or
fuser -m /mnt/disk
To figure out which process is using a file on the filesystem mounted on /mnt/disk.
Note that the fuser command should probably be run as root (use sudo) to be useful.

autofs

 
Quote:

There is also an "autofs" option, which I gather is supposed to detect the filesystem for you automatically, but I've never gotten it to work (nor have I had much need for it).

Newbe assumptions are sometimes very funny Laughing out loud (No offence)
Actually autofs is used with the automount deamon (installed by the "autofs" package in Debian/Ubuntu) to allow for automatic (un)mounting of filesystems.
For example, you can set it up to automatically mount a shared directory over the network when you go into the /netshares/myserver/shared_files directory (directory names given are just for example).
In fact the "autofs" package includes some scripts to enable things like automatically mounting every windows share on the network by going into /smb/<hostname>/<sharename> or every NFS (unix) share by going into /net/<hostname>/<export-path>
Autofs was made as a tool for sysadmins to enable users to mount stuff without having to enable "sudo" for them or even teach them what "mount" is...

With regard to auto-detecting the filesystem type you can use:
mount -t auto ...
or not specify "-t" at all and "mount" will try to detect the filesystem type, which it will get right in most cases (its a little more complicated then that actually, details are, as ususal, in the manpage...)

smbfs

 
Quote:

Actually, there is a separate mount command, "smbmount," just for Windows shares, but you don't use it. Instead, when you mount an smbfs filesystem, the mount command calls smbmount for you.

Note that as far as I could see, on Ubuntu the "smbmount" command isn't installed by dafult, which causes some strange errors when trying to mount Windows shares.
To enable "smbmount" one needs to install the "smbfs" package e.g. run
sudo aptitude install smbfs
on the command-line, or simply select it in Synaptic.

Corrections welcome

 
ifb wrote:
Quote:

There is also an "autofs" option, which I gather is supposed to detect the filesystem for you automatically, but I've never gotten it to work (nor have I had much need for it).

Newbe assumptions are sometimes very funny Laughing out loud (No offence)

Even though I've been using Linux for 4 years -- 3 of them almost exclusively -- and I have managed to accomplish a lot of things that baffled me at first, I still feel like a newbie. I wrote this article because I had finally managed to figure out how to do what I needed with mounting, not because I felt like an expert.

I almost mentioned in the article that corrections and additions were welcome. Perhaps some time I will re-write it with the things I have learned from these comments.

Sincerely,
Derek

suggestions

I don't think we've ever had someone submit an article as the first thing they put on this site, but thanks. Smiling I hadn't heard of the -l option before.

I made some formatting changes in your article (replacing -- with &mdash;, putting titles in <h2> elements, capitalizing CD-ROM (It's an acronym.)), although I haven't made any changes to the meaning.

Now time for ACCâ„¢, a thing's Candid Critcismâ„¢:

You might want to add a note that device naming schemes differ between kernels. If you use Mach or a BSD, this part of the tutorial doesn't apply.

Ending directory names in a slash will help make it clearer that they're directories, not normal files.

Using "file" instead of "cat" on the USB device to find if it exists would work without not fill your console with garbage.

Things can be combined in one directory with UnionFS (Ionno how to do this though, I've never needed it).

The reason pulling a device out by force is bad is because it's mounted asychronously by default. This can be controled with the sync and async options. Asynchronous writing means that not everything is written right away, but when the best time occurs. This speeds up writing (most of the time—I've no idea why). When you forceably take out the device, the best time for asynchronous writing may not have occured yet.

Samba isn't a protocol, it's an implementation of the SMB (Server Message Block) protocol.

Every filesystem, not just smbfs, has its own separate program called by mount.

libervisco, signitures should be attached to comments on things other than forums too.

asynchronous writing speed

a thing wrote:

Asynchronous writing means that not everything is written right away, but when the best time occurs. This speeds up writing (most of the time—I've no idea why).

For disks, waiting a while and collecting the data means the data can be ordered such that it can be written in one sweep of the arm.

Flash memory can't be written one byte at a time, it must be written in large blocks. This causes a problem similar to filesystem fragmentation, which is less likely to happen if data is written bursts larger than those blocks. Furthermore, writing a block of flash takes a long time, so it's better to write a block once than it is to write it a few times.

Also, some programs will write something, and write to the same location again very soon. Doing that in a cache in RAM is much faster than on disk or flash.

Finally, asynchronous writing means the program doesn't have to wait for the real write to finish, so response time will be better. That's not the same thing as higher writing speed, though. In the case where a program writes a large amount of data, in the right order, and then doesn't access the same data again, a synchronous write would be slightly faster (no copying data around in RAM).

I just tried mount -t

 

I just tried

mount -t iso9660 /dev/hdb1 /mnt/cdrom -o rw,omask=000

same with hdb6 or hdb instead of hdb1.

I get a message saying

[root@localhost rscheng]# mount -t iso9660 /dev/hdb1 /mnt/cdrom -o rw,omask=000
mount: /dev/hdb1 already mounted or /mnt/cdrom busy
mount: according to mtab, /dev/hdb1 is mounted on /
[root@localhost rscheng]# mount -t iso9660 /dev/hdb6 /mnt/cdrom -o rw,omask=000
mount: /dev/hdb6 already mounted or /mnt/cdrom busy
mount: according to mtab, /dev/hdb6 is mounted on /home
[root@localhost rscheng]# mount -t iso9660 /dev/hdb /mnt/cdrom -o rw,omask=000
mount: /dev/hdb already mounted or /mnt/cdrom busy
mount: according to mtab, /dev/hda is already mounted on /mnt/cdrom
[root@localhost rscheng]#

when I device:konqueror

I see

CD-ROM (hda) .... 0B Mounted CD-ROM

but I put a disc in and double-click the link, I get

no items - no folder [never mind]

It went thru?!? I'm copyied the disk. Strange?!?
Any clue on what is happening.

Sheng-Chieh