TOC
GNOMEデスクトップのNautilusのクローンであるCajaについての概要
MATE1というデスクトップ環境は元々GNOME2からGNOME3への変更が大きすぎたためにGNOME2をメンテナンスしていくために誕生したデスクトップ環境で、GNOME2のアプリはクローンした上でメンテナンスを続けています。クローンの際に名称を変更しており、代表的なところでは以下のものがあります。
- Caja(GNOME名Nautilus)
- Pluma(GNOME名Gedit)
- Atril(GNOME名Evince)
- MATE Terminal(GNOME名GNOME Terminal)
- Engrampa(GNOME名Archive Manager)
CajaはファイルマネージャであるNautilusと外見は同じですが、ヘルプ→情報と辿ると本来のクレジットが表示されてCajaであることがわかります。
ある日突然読み込み専用でマウントしてしまう体に…
そんなCajaですが、(おそらくNautilusの頃からあった気がする)外部ファイルシステムのマウント機能があり、これを使うことで他のパーティションをマウスクリックひとつでマウントできるようになっています。
私の場合、Ubuntu MATEをインストールしているパーティションとは別にWindows10をインストールしていてデュアルブート構成にしていることから、NTFSパーティションを簡単にマウントでき、その時はファイルの読み書きもできていたのです。
ところがある日(先週あたり)、いつも通りWindows上で作業したいファイルをコピーしようとしたところこんな表示が。
うーん。地味にめちゃくちゃ困る。クリックひとつでできるのが楽だったのと、アンマウントして再度マウントしてみても状況が変わらなかったので、どうしたものかとざっくり検索。
caja-mounted USB media sometimes incorrectly appear read-only · Issue #565 · mate-desktop/caja
issueは閉じられていないものの、最後にそれっぽい情報が載っていたので諸々確認してみました。
私の場合の情報は
- Cajaでマウントした際のマウントポイントは
/media/hogehoge/DE3AE61C3AE5F187/ ~/.local/share/gvfs-metadataの下にあるファイルはuuid-DE3AE61C3AE5F187とuuid-DE3AE61C3AE5F187-a216f788.log
gvfs-infoコマンドを実行してみます。
$ gvfs-info -f /media/hogehoge/DE3AE61C3AE5F187/
This tool has been deprecated, use 'gio info' instead.
See 'gio help info' for more info.
属性:
filesystem::size: 250959814656
filesystem::free: 111071199232
filesystem::type: fuse
filesystem::readonly: TRUE
filesystem::used: 139888615424
filesystem::remote: FALSE
deprecatedとのことなので、一応gio infoコマンドも実行してみました。結果は同じです。
$ gio info -f /media/hogehoge/DE3AE61C3AE5F187/
属性:
filesystem::size: 250959814656
filesystem::free: 111071199232
filesystem::type: fuse
filesystem::readonly: TRUE
filesystem::used: 139888615424
filesystem::remote: FALSE
この中で、filesystem::readonly: TRUEになっているところを何とかする必要がありそうです。
githubのissueのコメントでは~/.local/share/gvfs-metadataの下にあるIDが同じファイル2を削除するということなので、アンマウントしてから削除してみます。
$ rm ~/.local/share/gvfs-metadata/uuid-DE3AE61C3AE5F187-a216f788*
結果→変化なし！
作業をしていく中で、Cajaのパーティションマウント機能が裏でgioコマンドを使っていることがわかったので、今度はそっち方面で検索すると…Ubuntuの場合Disksを起動してNTFSパーティションを修復すると治るという話がみつかりました。
Windows8以降のNTFSに搭載される高速スタートアップ
デュアルブートの場合に定番とされる「高速スタートアップ」の無効化ですが、今回は設定を忘れていました。
その「高速スタートアップ」の機能概要ですが、
高速スタートアップ
Windows 8 以上には高速スタートアップという新しい機能が含まれており、シャットダウンを実際に行う代わりにハイバネートをすることで起動時間を短縮します。Windows がハイバネートを行なっているときに、他の OS にデュアルブートしてファイルに変更を加えてしまうと、ファイルシステムのデータを消失してしまう可能性があります。ファイルシステムを共有する予定がない場合でも、EFI 環境では ESP が破壊されるおそれが存在します。従って、Windows 8 を使っているコンピュータでは、Linux をインストールする前に (Windows 8 の場合) や (Windows 10 の場合) に記述されているようにして高速スタートアップを無効にしてください。
ハイバネートされたディスクを読み書きでマウントすることを防ぐセーフガードが NTFS-3G には追加されています が、Linux カーネルの NTFS ドライバーにはそうしたセーフガードが存在しません。
ハイバネートはPCをシャットダウンする代わりにRAMの状態をすべてディスクに書き出すことで、次回起動時にディスクからRAMに読み出すことでOSの起動の代わりに状態を保持できるようにする仕組みですが、コールドブートにかかる時間がSSDの場合はかなり短いので、そんなにメリットがないしデュアルブートの場合は使わないほうが良いかなというものです。
また、おそらくgioによるNTFSパーティションのマウントはntfs-3gを使っているので、ハイバネートされたディスクを読み書きでマウントすることを防いだ結果、書き込みができていないというのも辻褄が合います。
Windows10で高速スタートアップを解除する
この項目はWindowsでデフォルトで設定されますが、恐らく初めて発動したのがWindows Update後の自動再起動かなにかで、その後から動作が変わったので設定を変更します。
スタートメニュー→W→Windowsシステムツール→コントロールパネルを選択します。
表示方法を大きいアイコンに変更し、下の方にある電源オプションを選択します。
左側にある「電源ボタンの動作を選択する」をクリックします。
「現在利用可能ではない設定を変更します」をクリックします。
「高速スタートアップを有効にする（推奨）」のチェックを外して保存します。
Windowsでの設定変更はこれで終了です。再度別パーティションのUbuntu MATEを起動して、gio infoコマンドで状態を確認します。
$ gio info -f /media/hogehoge/DE3AE61C3AE5F187/
属性:
filesystem::size: 250959814656
filesystem::free: 130481328128
filesystem::type: fuse
filesystem::used: 120478486528
filesystem::remote: FALSE
filesystem::readonly: の行がなくなりました。そして再びNTFSパーティションに書き込みが可能に。
(補足)調査の途中でやってみたこと
Windowsを起動して高速スタートアップを解除する前にやってみたことを備忘録として記載します。
gnome-disks-utilityをインストールします。
# apt-get install gnome-disk-utility
Disksを起動します。コマンドからはgnome-disksコマンドで起動できます。
パーティション3がWindows10が入っているパーティションなので、選択して「ファイルシステムを修復」をしてみます。
失敗しますが、このエラーメッセージの「Windows is hibernated, refused to mount.」がWindows側のハイバネートによるものであることがわかります。
スポンサーリンク
comments powered by Disqus