![选项“user”适用于挂载,不适用于卸载](https://linux22.com/image/32191/%E9%80%89%E9%A1%B9%E2%80%9Cuser%E2%80%9D%E9%80%82%E7%94%A8%E4%BA%8E%E6%8C%82%E8%BD%BD%EF%BC%8C%E4%B8%8D%E9%80%82%E7%94%A8%E4%BA%8E%E5%8D%B8%E8%BD%BD.png)
我正在试验我正在编写的程序的安装选项。我正在运行 Linux Mageia 2。
我添加了以下行/etc/fstab
/dev/sr0 /mem auto user,noauto, 0 0
我删除了有关/dev/sr0
DVD 驱动器设备的所有其他条目。
然后,作为普通用户,我可以成功
$ mount /dev/sr0
但随后我收到一条错误消息(“只有 root 可以...”)
$ umount /dev/sr0
当然,设备并不繁忙:我在挂载和卸载之间不执行任何操作。
解决后添加:如果您只对解决该问题感兴趣,则可以跳过问题的其余部分,直接转到已接受的答案。问题的其余部分是关于我寻找解决方案或更好地记录问题的工作。然而,有一个尸检问题最后的部分用我自己的评论补充了答案。
文件的所有权:
$ 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 的第一个回复并没有带来进一步的见解,因为如果我对卸载过程的理解是正确的话,它基本上与我使用的相同。然而,它让我进一步思考这个过程(因此投了一张赞成票)并获得更多细节。 Hauke Laging 的评论更加支持了这一点。据我了解,概括地说, umount 命令采用其参数(设备或安装点)并尝试识别适用的条目,/etc/mtab
然后检查/etc/fstab
它是否可以执行请求。
根据mount(8) 的手册页,安装用户的名称[应该]写入 mtab 以便他可以再次卸载文件系统。
当我/etc/mtab
安装后检查时,没有找到这样的信息。我不知道它应该如何存储以及它应该是什么样子。
因此,问题实际上是与mount
而不是与umount
。
为了绝对确定问题不是/etc/fstab
使用另一个条目进行安装(这将解释对“用户”选项的无知),我删除了 中的所有其他条目/etc/fstab
,只保留问题开头的一行。然后我重复了安装-卸载顺序,不幸的是得到了相同的结果。
$ 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 解决问题后的一些总结。
我在网上遵循了豪克的解释。
显然这是一个老问题了。它的解释是2000年10月的旧文件,提到其他选项的一些问题,但没有user
。希望一些内核可靠性问题现在得到纠正。
该问题在错误部分中被简要提及mount
手册页
但不够详细,特别是关于替代设置和对选项的影响。
然而,在那篇很长的手册页中丢失了以下信息:
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**.
user
在描述选项的地方提供有关此的提示肯定会很有用,这是我首先查看的地方。
答案1
问题是您的/etc/mtab
不是文件而是/proc/mounts
.这有优点,但也user
有不起作用的缺点。您已经猜对了原因:“系统在记住谁安装了文件系统时会感到困惑”。此信息被写入mtab
,但在您的情况下不能写入其中。内核不关心(甚至不知道)用户挂载(这是用户空间功能)。因此,此信息不包含在/proc/mounts
.
做这个:
cd /etc
cp mtab mtab.file
rm mtab
mv mtab.file mtab
umount
用户应该在再次安装该卷后才能工作。
答案2
尝试使用挂载点代替设备 ( /dev/sr0
) 名称(在您的情况下挂载点是/mem
)
所以只需用于安装:
mount /mem
对于卸载使用:
umount /mem
我已经测试并在我身边工作,操作系统是 CentOS 5.8