私が書いているプログラムのマウントオプションを実験しています。 Linux Mageia 2を実行しています。
/etc/fstab
に次の行を追加しました
/dev/sr0 /mem auto user,noauto, 0 0
そして、DVDドライブのデバイスである/dev/sr0
に関する他のすべてのエントリを削除しました。
次に、通常のユーザーとして、私は正常にできます
$ mount /dev/sr0
しかし、次のエラーメッセージが表示されます( "rootのみが...")
$ umount /dev/sr0
もちろん、デバイスはビジーではありません。mountとumountの間では何もしません。
解決後に追加:その問題の解決のみに関心がある場合は、残りの質問をスキップして、受け入れられた答えに直接。残りの質問は、解決策を見つけるか、問題をより適切に文書化するための私の仕事についてです。ただし、質問の最後にa死後)セクションがあり、自分のコメントで回答を補完しています。
ファイルの所有権:
$ 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による最初の応答は、私が使用したものと本質的に同等であるため、これ以上の洞察は得られません。しかし、私はこのプロセス(したがって1つの賛成票)についてさらに考え、詳細を取得することにしました。これは、Hauke Lagingのコメントによってさらに支持されました。私が理解しているように、要約すると、umountコマンドは引数(デバイスまたはマウントポイント)を取得し、/etc/mtab
内の該当するエントリを識別して、/etc/fstab
でリクエストを実行できるかどうかを確認します。
mount(8)のmanページ 、に従って、マウントするユーザーの名前[すべきである]mtabに書き込まれるマウント後に/etc/mtab
を確認すると、そのような情報が記載されていません。それがどのように格納されることになっているのか、どのように見えるべきなのか、私にはわかりません。
したがって、問題は実際にはmount
ではなくumount
にあります。
問題が別の/etc/fstab
エントリがマウントに使用されていることではないことを確実にするために(「user」オプションが無視されていることを説明します)、/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に感謝しますが、なぜその質問をしたのですか?
実際、ファイルは私のものではありません。私はそれが仮想ファイルでなければならないことを推測します。ユーザー「友達」としてリクエストを繰り返し、次に「ルート」としてリクエストを繰り返しました。
$ 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
manページ のバグセクションで簡単に説明されていますが、特に代替のセットアップとオプションへの影響に関しては、十分に詳しくはありません。
ただし、その非常に長いmanページでは、次の情報が失われています。
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
が記述されている場所について、私が最初に調べた場所についてのヒントがあると確かに役立ちます。
問題は、あなたの/etc/mtab
がファイルではなく/proc/mounts
へのシンボリックリンクであることです。これには利点がありますが、user
が機能しないという欠点もあります。 「ファイルシステムをマウントしたユーザーを覚えていると、システムが混乱する」という理由はすでにおわかりでしょう。この情報はmtab
に書き込まれますが、あなたのケースではそこに書き込むことはできません。カーネルはユーザーマウント(これはユーザー空間機能です)を気にしません(知らないこともあります)。したがって、この情報は/proc/mounts
に含まれていません。
これを行う:
cd /etc
cp mtab mtab.file
rm mtab
mv mtab.file mtab
umount
は、ボリュームを再度マウントした後に作業する必要があるためです。
デバイス(/dev/sr0
)名の代わりにマウントポイントを使用してみてください(この場合、マウントポイントは/mem
です)
したがって、マウントに使用するだけです:
mount /mem
アンマウント用:
umount /mem
私はテストして私の側で働いています、OSはCentOS 5.8です