Option "user" work for mount, not for umount

Question

I am experimenting mounting options for a program I am writing. I am running Linux Mageia 2.

I added the following line to /etc/fstab

/dev/sr0 /mem  auto user,noauto, 0 0

and I removed all other entries regarding /dev/sr0 which is the device for my DVD drive.

Then, acting as normal user, I can successfully

$ mount /dev/sr0

but I then get an error message ("Only root can ...") for

$ umount /dev/sr0

Of course, the device is not busy : I do nothing between mount and umount.

Added after solving : If you are interested only in solving that problem, you can skip the rest of the question, and go directly to the accepted answer. The rest of the question is about my work to find a solution or better document the problem. However, there is a post-mortem section at the very end of the question that complements the answer with my own remarks.

Ownership of files :

$ ls -ld /mem /dev/sr0
brw-rw----+  1 root cdrom 11, 0 mai   14 01:01 /dev/sr0
drwxr-xr-x  12 root root   4096 janv. 21 22:34 /mem/

And I am a member of the group "cdrom"

I have the very same problem when mounting a file system image with a loop device.

However, everything works fine when I replace "user" with the option "users", which seems to indicate that the system is confused when remembering who mounted the file system.

The first reply by Rahul Patil does not bring further insight since it is essentially equivalent to what I used, if my understanding of the umounting procedure is correct. However it lead me to think further about this process (hence one upvote) and to get more details. This was even more supported by the comment of Hauke Laging. As I understand it, summarily, the umount command takes its argument (a device or a mount point) and tries to identify applicable entries in /etc/mtab and then checks with /etc/fstab whether it can execute the request.

According to the man page for mount(8),the name of the mounting user [should be] written to mtab so that he can unmount the filesystem again. When I check /etc/mtab after mounting, there is no such information written that I can find. I do not know how it is supposed to be stored and what it should look like.

Hence the probleme is really with mount rather than with umount.

To be absolutely sure that the problem is not that another /etc/fstab entry is used for mounting (which would explain ignorance of the "user"option), I deleted all other entries in /etc/fstab, keeping only the single line at the beginning of my question. Then I repeated the mount-umount sequence, unfortunately with the same result.

$ grep sr0 /etc/mtab
/dev/sr0 /mem udf ro,nosuid,nodev,noexec,relatime,utf8 0 0

$ mount | grep sr0
/dev/sr0 on /mem type udf (ro,nosuid,nodev,noexec,relatime,utf8)

Hauke Laging asked for ls -l /etc/mtab, which I thought was an error and that he was really asking for cat /etc/mtab. But I did it anyway ...

$ ls -l /etc/mtab
lrwxrwxrwx 1 root root 12 juin  25  2012 /etc/mtab -> /proc/mounts
$ ls -l /proc/mounts
lrwxrwxrwx 1 root root 11 mai   19 13:21 /proc/mounts -> self/mounts
$ ls -l /proc/self/mounts
-r--r--r-- 1 myself mygroup 0 mai   19 13:22 /proc/self/mounts

This last information surprised me. Though I am essentially the only user on that computer, I see no reason why this file should belong to me, or to any other user than root itself. Many thanks Hauke, but why did you ask that question ?

Actually the file does not belong to me. I guess it must be a virtual file. I repeated the request as user "friend", and then as "root":

$ ls -l /proc/self/mounts
-r--r--r-- 1 friend users 0 mai   19 14:10 /proc/self/mounts

# ls -l /proc/self/mounts
-r--r--r-- 1 root root 0 mai   19 14:10 /proc/self/mounts

I would welcome any suggestion as to what the problem might be, or for experiments to attempt.

Thanks

Post-mortem: here are some final remarks after the problem was solved by Hauke Laging.

I followed on the web the lead of Hauke's explanation.

Apparently this is an old issue. It is explained in an old document from october 2000, mentionning some problems with other options, but not user. Hopefully some of the kernel reliability issues are now corrected.

The issue is briefly mentionned in the bug section of the mount man page but not in enough detail, especially regarding alternative setups and effect on options.

However, lost in that very long man page is the following information:

When the proc filesystem is mounted (say at /proc), the files
/etc/mtab and /proc/mounts have very similar contents. **The
former has somewhat more information, such as the mount options
used**, but is not necessarily up-to-date (cf. the -n option
below). It is possible to replace /etc/mtab by a symbolic link to
/proc/mounts, and especially when you have very large numbers of
mounts things will be much faster with that symlink, but **some
information is lost that way, and in particular using the "user"
option will fail**.

It would certainly have been useful to have a hint about this where the option user is described, which is the first place I looked.

Answer 1

The problem is that your /etc/mtab is not a file but a symlink to /proc/mounts. This has advantages but also the disadvantage that user does not work. You already guessed right the reason for that: "the system is confused when remembering who mounted the file system". This information is written to mtab, cannot be written there in your case though. The kernel doesn't care (doesn't even know) about user mounts (this is a userspace feature). Thus this info is not contained in /proc/mounts.

Do this:

cd /etc
cp mtab mtab.file
rm mtab
mv mtab.file mtab

umount as user should work after you have mounted the volume again.

Answer 2

instead of device (/dev/sr0) name try using mount point (in your case mount point is /mem)

So just use for mount:

mount /mem

For unmount use :

umount /mem

I have tested and Working in my side, OS is CentOS 5.8