Option "user" work for mount, not for umount

9,492

Solution 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.

Solution 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

Share:
9,492
babou
Author by

babou

Updated on September 18, 2022

Comments

  • babou
    babou over 1 year

    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.

    • Hauke Laging
      Hauke Laging about 11 years
      Is it the same user which does both operations?
    • Hauke Laging
      Hauke Laging about 11 years
      What is the output of mount after the device has been mounted? And ls -l /etc/mtab?
    • babou
      babou about 11 years
      @Hauke Laging -- Why did you ask for ls -l /etc/mtab ?
    • Hauke Laging
      Hauke Laging about 11 years
      See my answer below.
    • Hauke Laging
      Hauke Laging about 11 years
      /proc/self is just a symlink to /proc/$PID of the calling process. About the man page problem: Feel free to improve the text. I am sure the maintainers will be happy.
  • babou
    babou about 11 years
    Why should /mnt have anything to do with it. It is not part of my mounting setup. Or did you mean "umount /mem" ? Anyway, it does not work.
  • Rahul Patil
    Rahul Patil about 11 years
    can you remove comma after permission like user,noauto, change to user,noauto from your fstab
  • babou
    babou about 11 years
    Thank you for the remark. The comma is the result of simplifications of the /etc/fstab entry I made after I encountered the problem ... which unfortunately persists without the comma. However your remark allowed me to clean also another entry in stackexchange which actually motivated my question.