オプション「user」は、アンマウントではなくマウントに適用されます。

作成中のプログラムのインストールオプションを試しています。私はLinux Mageia 2を実行しています。

次の行を追加しました。/etc/fstab

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

/dev/sr0DVDドライブデバイスの他のすべての項目を削除しました。

その後、一般ユーザーとして正常に

$ mount /dev/sr0

ところで、エラーメッセージが表示されます（「ルートのみ...」）。

$ 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」グループのメンバーです

ループデバイスを使用してファイルシステムイメージをマウントするときにも同じ問題が発生しました。

ただし、「user」を「users」オプションに置き換えると、すべてがうまく機能します。これは、ファイルシステムをマウントした人を覚えているときにシステムが混乱していることを示しているようです。

Rahul Patilの最初の回答は、削除プロセスの理解が正しい場合、基本的に私が使用する回答と同じであるため、追加の洞察を提供しません。しかし、これにより、プロセス（したがって賛成）についてより深く考えるようになり、より詳細な情報を得ることができるようになりました。 Hauke Lagingのレビューはこれをさらに支持します。私が理解しているように、umountコマンドはその引数（デバイスまたはマウントポイント）を取得し、適用可能なエントリを識別し、要求を実行できることを確認/etc/mtabし/etc/fstabます。

~によるとmount(8) のマニュアルページ、インストールユーザー名[しなければならない]ファイルシステムを再マウント解除できるようにmtabに書き込みます。 インストール後に確認してみると、/etc/mtabそのような情報は見つかりませんでした。どのように保管しなければならないのか、どのような姿であるべきかわかりません。

したがって、質問は実際にはANDmountではなくANDです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

最後のメッセージは私を驚かせた。本質的に私はこのコンピュータの唯一のユーザーですが、このファイルが私またはルート自体以外の他のユーザーに属する理由はありません。 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の説明に従いました。

明らかにこれは古い問題です。その説明は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オプションが説明されている場所（私が最初に見ている場所）についてのヒントがあれば、確かに役に立ちます。