我正在尝试为我正在编写的程序安装选项.我正在运行Linux Mageia 2.

我在/ etc / fstab中添加了以下行

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

我删除了有关/ dev / sr0的所有其他条目,这是我的DVD驱动器的设备.

然后,作为普通用户,我可以成功

$mount /dev/sr0

但我得到一条错误消息(“只有root可以……”)

$umount /dev/sr0

当然,设备不忙：我在mount和umount之间什么都不做.

解决后添加：如果您只对解决该问题感兴趣,可以跳过其余问题,直接转到接受的答案.
问题的其余部分是关于我找到解决方案或更好地记录问题的工作.然而,在问题的最后部分有一个验尸部分,用我自己的评论补充答案.

文件所有权：

$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/

我是“cdrom”组的成员

使用循环设备安装文件系统映像时遇到同样的问题.

但是,当我用“users”选项替换“user”时,一切正常,这似乎表明在记住谁挂载文件系统时系统很困惑.

Rahul Patil的第一个回复并未带来进一步的见解,因为如果我对卸载程序的理解是正确的,那么它基本上与我使用的相同.然而,它引导我进一步思考这个过程(因此一个upvote)并获得更多细节. Hauke Laging的评论更为支持.据我所知,概括地说,umount命令获取其参数(设备或挂载点)并尝试在/ etc / mtab中标识适用的条目,然后检查/ etc / fstab是否可以执行请求.

根据man page for mount(8),安装用户的名称[应该]写入mtab,以便他可以再次卸载文件系统.
当我在安装后检查/ etc / mtab时,没有写出我能找到的信息.我不知道应该如何存储它应该是什么样子.

因此问题实际上是mount而不是umount.

要绝对确定问题不是另一个/ etc / fstab条目用于挂载(这可以解释对“用户”选项的无知),
我删除了/ etc / fstab中的所有其他条目,只保留了我的问题开头的单行.然后我重复了mount-umount序列,遗憾的是结果相同.

$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要求ls -l / etc / mtab,我认为这是一个错误,他真的要求cat / etc / mtab.但无论如何我做到了……

$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

这最后的信息让我很惊讶.虽然我本质上是该计算机上唯一的用户,但我认为没有理由为什么这个文件属于我,或者除了root本身之外的任何其他用户.非常感谢Hauke,但你为什么问这个问题呢？

实际上该文件不属于我.我想它必须是一个虚拟文件.我以用户“friend”重复请求,然后以“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

我欢迎任何关于问题可能是什么或者尝试实验的建议.

谢谢

验尸：这是Hauke Laging解决问题后的最后一些评论.

我在网上关注了Hauke的解释.

显然这是一个老问题.它在old document from october 2000中解释,提到了其他选项的一些问题,但不是用户.
希望现在可以纠正一些内核可靠性问题.

在mount man page的bug部分简要提到了这个问题
但不够详细,尤其是关于替代设置和对选项的影响.

但是,在那个很长的手册页中丢失了以下信息：

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

在描述选项用户的情况下提供关于此的提示肯定是有用的,这是我看到的第一个地方.

解决方法:

问题是您的/ etc / mtab不是文件,而是/ proc / mounts的符号链接.这具有优点,但也具有用户不工作的缺点.您已经猜到了正确的原因：“在记住谁挂载文件系统时,系统会感到困惑”.此信息写入mtab,但在您的情况下不能写入.内核不关心(甚至不知道)用户安装(这是用户空间功能).因此,此信息不包含在/ proc / mounts中.

做这个：

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

umount,因为用户应该在您再次装入卷后工作.