Ubuntuサーバーの仮想マシンにVMWareツールをインストールしようとしましたが、/ mntディレクトリにcdromディレクトリを作成できないという問題に遭遇しました。次に、それが単なるアクセス許可の問題かどうかをテストしましたが、ホームディレクトリにフォルダーを作成することさえできませんでした。読み取り専用のファイルシステムであると述べ続けています。 Linuxについて少し知っていますが、まだ慣れていません。何かアドバイスをいただければ幸いです。
コメントから要求された情報:
ユーザー名@サーバー名:〜$マウント
/dev/sda1 on /タイプext4(rw、errors = remount-ro)
proc/procタイプproc(rw)
/sysタイプsysfs(rw、noexec、nosuid、nodev)にはなし
/sys/fs/Fuse/connectionsにnoneタイプのfusectl(rw)
/sys/kernel/debugタイプdebugfs(rw)にはなし
/sys/kernel/securityタイプsecurityfs(rw)にはなし
/devタイプのtmpfs上のudev(rw、mode = 0755)
/dev/ptsタイプdevpts(rw、noexec、nosuid、gid = 5、mode = 0620)にはなし
/dev/shmタイプtmpfs(rw、nosuid、nodev)にはなし
/var/runタイプtmpfsにはなし(rw、nosuid、mode = 0755)
/var/lockタイプのtmpfsにはありません(rw、noexec、nosuid、nodev)
/lib/init/rwタイプのtmpfsにはなし(rw、nosuid、mode = 0755)/ proc/sys/fs/binfmt_miscタイプのbinfmt_misc binfmt_misc(rw、noexec、nosuid、nodev)
確かにルート出力。
root @ server01:〜#マウント
/dev/sda1 on /タイプext4(rw、errors = remount-ro)
proc/procタイプproc(rw)
/sysタイプsysfs(rw、noexec、nosuid、nodev)にはなし
/sys/fs/Fuse/connectionsにnoneタイプのfusectl(rw)
/sys/kernel/debugタイプdebugfs(rw)にはなし
/sys/kernel/securityタイプsecurityfs(rw)にはなし
/devタイプのtmpfs上のudev(rw、mode = 0755)
/dev/ptsタイプdevpts(rw、noexec、nosuid、gid = 5、mode = 0620)にはなし
/dev/shmタイプtmpfs(rw、nosuid、nodev)にはなし
/var/runタイプtmpfsにはなし(rw、nosuid、mode = 0755)
/var/lockタイプのtmpfsにはありません(rw、noexec、nosuid、nodev)
/lib/init/rwタイプのtmpfsにはなし(rw、nosuid、mode = 0755)/ proc/sys/fs/binfmt_miscタイプのbinfmt_misc binfmt_misc(rw、noexec、nosuid、nodev)
これは比較的古い質問ですが、答えは同じです。仮想マシン(物理ホストで実行中)と何らかのストレージ(共有ストレージ-FC SAN、iSCSIストレージ、NFS共有-またはローカルストレージ)があります。
仮想化により、多くの仮想マシンが同じ物理リソースに同時にアクセスしようとします。物理的な制限(読み取り/書き込み操作の数-IOPS、スループット、レイテンシ)により、すべての物理マシンのすべてのストレージ要求を同時に満たすことが問題になる場合があります。通常何が起こるか:仮想マシンのオペレーティングシステムで「SCSI再試行」と失敗したSCSI操作を確認できます。一定期間内にエラー/再試行が多すぎる場合、カーネルはファイルシステムへの損傷を防ぐために、マウントされたファイルシステムを読み取り専用に設定します。
簡単に言えば、物理ストレージは「強力」ではありません。同時にストレージシステムにアクセスするプロセス(仮想マシン)が多すぎるため、仮想マシンがストレージから十分な速度で応答を取得できず、ファイルシステムが読み取り専用になります。
できることはそれほど多くありません。明白な解決策は、より良い/追加のストレージです。 LinuxカーネルでSCSIタイムアウトのパラメーターを変更することもできます。詳細は、たとえば次の場所に記載されています。
http://www.cyberciti.biz/tips/vmware-esx-server-scsi-timeout-for-linux-guest.html
ただし、これは問題を「延期する」だけです。これは、カーネルがファイルシステムを読み取り専用に設定する前に、より多くの時間しか取得しないためです。 (つまり、問題の原因を解決していません。)
私の経験(VMwareで数年)は、この問題はLinuxカーネル(RHELとSLESを使用している)でのみ発生し、Windowsサーバーでは発生しないということです。また、この問題は、FC、iSCSI、ローカルストレージなど、あらゆる種類のストレージで発生します。私たちにとって、仮想インフラストラクチャで最も重要な(そして高価な)コンポーネントはストレージです。 (1 Gbps iSCSI接続でHP LeftHandを使用しており、それ以来ストレージの問題は発生していません。拡張性のために(従来のFCソリューションではなく)LeftHandを選択しました。
考えられる説明は、ハードウェアの問題(ディスクの部分的な障害)があり、問題を最小限に抑えるために、カーネルが問題を検出するとすぐにルートファイルシステムを読み取り専用として再マウントしたことです。現在のマウントオプションを確認するためのより信頼性の高い方法は、cat /proc/mounts
(ルートファイルシステムの場合はgrep ' / ' /proc/mounts
、ブートプロセスのアーティファクトであるrootfs / …
行を無視する)です。おそらく、rw,errors=remount-ro
がro
に変更されていることがわかります(他のオプションがさらに表示される場合があります)。
カーネルログには、ディスクアクセスエラーが先行するメッセージRemounting filesystem read-only
が含まれている可能性があります。ログは通常/var/log/kern.log
にありますが、これが現在読み取り専用のファイルシステム上にある場合、メッセージはそこに表示されませんが、前述のエラーは表示されます。 dmesg
コマンドを使用して、最新のいくつかのカーネルエラーを確認することもできます。
ちなみに、Ubuntuでは、マウントポイント(デスクトップインターフェイスで使用)の通常の場所は/media
(例:/media/cdrom0
)ですが、必要に応じて/mnt
または/mnt/cdrom
を使用できます。
¹ /etc/mtab
からのmount
レポート。ルートファイルシステムが読み取り専用の場合、/etc/mtab
を最新に保つことができません。
最近起こったのは、データセンターで停電があったことです。それ以来、サーバーには触れていません。データセンターが停電すると、VSphereは再起動されるまでUbuntuのファイルシステムを読み取り専用にします。私は再起動を試みたでしょうが、すべての監視を狂わせたくありませんでした。 Nagios(監視サービス)を停止しましたが、システムを再起動したので、すべてが正常に動作しています。すべての入力をありがとう。よろしくお願いします。
当たり前かもしれませんが、これを行おうとすると「ルート」ユーザーですか?/mntはルートによって所有され、ルートによってのみ書き込み可能です。また、起動時にエラーが発生したかどうかを確認することもできます。上記の出力は、/(および/ mnt)は、ブートプロセスでエラーが検出された場合にのみ読み取りで再マウントする必要があることを示しています。これは、mountコマンドで変更できます(つまり、r/wとして再マウントします)が、エラーの原因が深刻でないことが確実でない限り、私はこれを行いません。