コンテンツにスキップ

「デュアルブート」の版間の差分

提供: Turgenev's Wiki
Notion-MW
Notion-MW
 
40行目: 40行目:
<syntaxhighlight lang="javascript">/dev/sda2    /media/ddrive ntfs-3g noauto,rw,nofail 0  0</syntaxhighlight></li></ul>
<syntaxhighlight lang="javascript">/dev/sda2    /media/ddrive ntfs-3g noauto,rw,nofail 0  0</syntaxhighlight></li></ul>


<span id="bislocker有り"></span>
<span id="bitlocker有り"></span>
=== Bislocker有り ===
=== Bitlocker有り ===


ntfs&#45;3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http&#58;//www7390uo.sakura.ne.jp/wordpress/archives/2]
ntfs&#45;3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http&#58;//www7390uo.sakura.ne.jp/wordpress/archives/2]
63行目: 63行目:
recovery&#45;passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション(LUKSとか?)やユーザーログイン時に復号される暗号化フォルダ(ecryptfsとか)といったディスク上で暗号化される領域に書いておく必要がある(もちろん毎回パスワードの類を打ち込むのでよければそれでもいい)。
recovery&#45;passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション(LUKSとか?)やユーザーログイン時に復号される暗号化フォルダ(ecryptfsとか)といったディスク上で暗号化される領域に書いておく必要がある(もちろん毎回パスワードの類を打ち込むのでよければそれでもいい)。


=== permissionsについて ===
<span id="permissions-inheritについて"></span>
=== permissions, inheritについて ===


[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https&#58;//github.com/tuxera/ntfs&#45;3g/wiki/File&#45;Ownership&#45;and&#45;Permissions] ここに書いてある。
[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https&#58;//github.com/tuxera/ntfs&#45;3g/wiki/File&#45;Ownership&#45;and&#45;Permissions] 詳しくはこちらも参照。


NTFSでのパーミッションの扱いとPOSIXでのパーミッションの扱いがかなり異なるため、WindowsとLinuxでパーティションをうまく共用するのは(特に各ユーザーフォルダ内に関しては)難しい。
まず、マウントオプションとして<strong>permissions</strong>を指定しない限り、ntfs&#45;3gでマウントしたファイルは全てパーミッション・所有者が固定(uid, gid, umaskなどで指定)となり、個別のファイルについて変更することはできない。


まず、ntfs&#45;3gでUserMappingを指定しない限りは、Linux上で新規作成したファイルは全てAdministratorsの所有物になる。また、特に指定がない限りはそれらのアクセス権はEveryoneがフルコントロールできる状態になる。もちろん親フォルダのアクセス権がなければ見えてしまうことはないが、エクスプローラー上でも周りのファイルとは明確にアクセス権がズレてしまう。なお、inheritオプションを使って上位フォルダの権限を継承することはできるが、所有者が違えばまともに継承もされないのであまり意味がない。
そして、この場合、ntfs&#45;3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される(この動作を変更するのは筆者の知る限り不可能)。


また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる。(実行権限を外すと.exeなどが実行できなくなる)
Linuxではフォルダの実行権限(x)が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである(試した限り)。そのため、permissions無しでntfs&#45;3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。


したがって、少なくともntfs&#45;3gにちゃんとしたUserMappingを与えない限りは、各ユーザーフォルダに作成したファイルを自動的にそのユーザーの所有物にするようなことは不可能である。
従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。


=== 特定ユーザーとしてmount ===
次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり(ここはpermissionsがない場合と同じ)、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS&#45;1&#45;5&#45;21&#45;3141592653&#45;589793238&#45;462643383&#45;10000というような上位桁が円周率に由来する(この部分はハードコードされている)SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。


[https://ikb.hatenablog.com/entry/20110203/1296725898 https&#58;//ikb.hatenablog.com/entry/20110203/1296725898]のように
Windowsに挙動を近づけるための他のオプションとしては<strong>inherit</strong>というのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは<u>所有者を継承するオプションではない</u>(そして、所有者が違えばまともに継承もされない)。


<code>&#45;o uid&#61;$(id &#45;u),gid&#61;$(id &#45;g)</code>とする。ただしこれだと複数ユーザーで使えない。複数ユーザーで使うときは、UserMappingを使用する(WindowsでのユーザーとLinuxでのユーザーを対応づけたい場合はこちら)か、bindfsを使うとよい。(一旦rootでマウントしてから、各ユーザー向けにそのユーザーの権限でマウント)
以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに(Windows側の権限設定を汚染せずに)使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。
 
一方で、Administrator所有・全ユーザー閲覧可能(あるいは不可能)、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。
 
Linux側で別ユーザーの所有に見せたい場合は、上記のS&#45;1&#45;5&#45;21&#45;3141592653&#45;589793238&#45;462643383&#45;10000のようなSIDが見えてしまう状態でもよければ(かつ、権限設定にも問題がなければ)それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では(パスさえわかれば)対応する権限でアクセスができてしまうということに注意が必要である。
 
また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる(実行権限を外すと.exeなどが実行できなくなる)。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで(これがデフォルトであるため)コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。


==== bindfs ====
==== bindfs ====


既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。Gitとかで所有権エラーが出るのを防げて快適になる。
既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。


<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
<syntaxhighlight lang="python">sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>

2025年5月5日 (月) 10:30時点における最新版

このセクションは最新の情報を反映していない可能性があります。

WindowsとLinuxのデュアルブートにおいて役に立つ情報を記述する。古いメモを多く含む。Linuxのインストールも参照。

Windowsのプロダクトキー関連

作業のため一時的に非公開となっている可能性があります。履歴もご確認ください。

Bitlocker

とにかく前もって回復キーを保存しておくこと!!逆に回復キーさえあればBitlockerで大きなトラブルになることは多くない。

Windowsパーティション(NTFS)のマウント

このセクションは最新の情報を反映していない可能性があります。

remove_hiberfileについて

マウントが成功するにはWindowsが完全シャットダウンされている必要がある(またはそれが望ましい)。ただ、https://unix.stackexchange.com/questions/107978/cant-access-windows-drive-windows-is-hibernated-refused-to-mountにある通り、windowsを正しくシャットダウンしてもなぜか「ハイバーネートされててマウントできません」的なのが出ることがあるので、マウントオプションにremove_hiberfileを追加するとよい。

  • 高速スタートアップを無効にしているにもかかわらず完全シャットダウンされていないことがある気がしたので、Windowsでシャットダウン時に実行するスクリプトとして完全シャットダウンコマンドを追加したりした
  • デスクトップPCではだいたい不要?

Bitlocker無し

普通にntfs-3gを使う。数字など適宜読み替えること。主にWindowsのDドライブ想定。

  • コマンド例

    ntfs-3g -o remove_hiberfile /dev/nvme0n1p5 /media/win
    
  • fstabの例

    /dev/sda2     /media/ddrive ntfs-3g noauto,rw,nofail 0  0
    

Bitlocker有り

ntfs-3gの前にDislockerで暗号化を解除する。参考→http://www7390uo.sakura.ne.jp/wordpress/archives/2

dislocker-fileの方式だと一旦復号したのをファイルに書き出して静的にマウントするので、(事実上)readonlyとなる。よってdislocker-fuseを使う→https://www.systutorials.com/docs/linux/man/1-dislocker-fuse/

  • コマンド例

    $ sudo dislocker-fuse -V /dev/nvme0n1p3 --recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx -- /media/dl-fuse
    $ sudo mount -o loop,rw /media/dl-fuse/dislocker-file /media/win/
    
  • fstab例

    /dev/nvme0n1p3     /media/bitlocker     fuse.dislocker recovery-password=xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx-xxxxxx  0 0
    /media/bitlocker/dislocker-file   /media/win10   ntfs-3g   rw,nofail,remove_hiberfile,permissions 0  2
    

    と、二行に分けて記載する。

    • permissions については後述

セキュリティ問題

recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション(LUKSとか?)やユーザーログイン時に復号される暗号化フォルダ(ecryptfsとか)といったディスク上で暗号化される領域に書いておく必要がある(もちろん毎回パスワードの類を打ち込むのでよければそれでもいい)。

permissions, inheritについて

https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions 詳しくはこちらも参照。

まず、マウントオプションとしてpermissionsを指定しない限り、ntfs-3gでマウントしたファイルは全てパーミッション・所有者が固定(uid, gid, umaskなどで指定)となり、個別のファイルについて変更することはできない。

そして、この場合、ntfs-3g経由で作成したファイルはWindows側で見るとすべてAdministratorの所有となり、さらにEveryoneにフルコントロール権限が付与される(この動作を変更するのは筆者の知る限り不可能)。

Linuxではフォルダの実行権限(x)が無ければその中に含まれたファイルにはアクセスが通らず、パスを推測することも不可能だが、Windowsではたとえ一切権限のないフォルダであっても中にあるファイル・フォルダのパスがわかれば直接パスを打つことでアクセスが通ってしまうようである(試した限り)。そのため、permissions無しでntfs-3gで作成したファイルはパスさえわかればWindows上の全ユーザーが閲覧・編集・削除できる状態ということになる。

従って、Gitを使用する場合や複数ユーザーで使用したい場合などパーミッション管理が必要なデータを扱う場合はもちろん、単に中にあるデータを保護したいという場合でもpermissionsオプションを指定することが必須になる。

次に、permissionsを指定して、かつUserMappingを指定しない場合、Linux上でrootが所有するファイルをWindows側で見ると、全てAdministratorsの所有物になり(ここはpermissionsがない場合と同じ)、そのアクセス権はLinux上での見え方と概ね一致するように設定されるようである。他のユーザーが所有するファイルにはS-1-5-21-3141592653-589793238-462643383-10000というような上位桁が円周率に由来する(この部分はハードコードされている)SIDが割り当てられ、こちらもアクセス権が適切に設定される。UserMappingを指定することで、このSIDの部分の割り当てを変更することができる。

Windowsに挙動を近づけるための他のオプションとしてはinheritというのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは所有者を継承するオプションではない(そして、所有者が違えばまともに継承もされない)。

以上のことから、Windowsの一般ユーザーフォルダの内容などをLinuxから良い感じに(Windows側の権限設定を汚染せずに)使えるようにするには、明示的なUserMappingが事実上必須であることがわかる。

一方で、Administrator所有・全ユーザー閲覧可能(あるいは不可能)、といった、Windows側の全ての一般ユーザーに対して共通のアクセス権を適用する設定であれば、UserMappingを使用しなくても簡単に設定が可能である。個人用PCかつ、画像・動画などのメディアファイルやLinuxでしか使用しない大きめのソフトウェアを入れておく用途であれば、こちらで問題ないだろう。

Linux側で別ユーザーの所有に見せたい場合は、上記のS-1-5-21-3141592653-589793238-462643383-10000のようなSIDが見えてしまう状態でもよければ(かつ、権限設定にも問題がなければ)それでもいいし、下記のbindfsと併用する方法もある。いずれにしても、Linux側で全員が読み取り・書き込み・実行が可能なファイルは、Linux側での親フォルダの権限によらず、Windows側では(パスさえわかれば)対応する権限でアクセスができてしまうということに注意が必要である。

また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる(実行権限を外すと.exeなどが実行できなくなる)。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで(これがデフォルトであるため)コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。

bindfs

既存のディレクトリを、所有ユーザーやパーミッションを変更してマウントしてくれる。

sudo bindfs --mirror=myname --force-group=myname /media/win ~/.mnt_win/

または

sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/

この2つの違いは不明

sudoがないとfusermount: option allow_other only allowed if 'user_allow_other' is set in /etc/fuse.confとか言われたりする

fstabの例

/media/win /home/myname/.mnt_win fuse.bindfs nofail,map=root/myname:@root/@myname,create-with-perms=g-w 0 0

Linuxだとrootのデフォルトのumaskが022で一般ユーザーが002なせいで一般ユーザーが作ったファイルが775とか664になってしまったりするがg-wをつけることによって755とか644になる(もちろんchmodすれば変えられる

Minecraft

.minecraftフォルダをWindowsとLinuxで共有したはいいが、(それ自体.minecraftの中にある)ゲームディレクトリの指定も共有することを考えると、両OSでパスの仕様がやや異なるのが問題になる。

例えば以下ではWindowsのルートが/media/winにマウントされているとする。

まずLinuxのランチャーは相対パスどころかシンボリックリンクすら変換して普通の絶対パスにしてしまう(設定を書き換えてしまう)っぽいので、linuxでは絶対パス指定で/media/win/Users/pathのようにする。で、この書き方をするとWindowsでは相対パスと解釈されるのだが、基準となるフォルダが謎で、「PLAY」を押した時のチェック時は.minecraftが基準なのだが、実際に見られるのはランチャーがあるフォルダが基準(=こっちになかった場合ゲームディレクトリが新たに作られる)

  • ストアアプリ版の(新しい方の?)Minecraftランチャーでは、この「ランチャーがあるフォルダ」はAppData\Local\Packages\Microsoft.4297127D64EC6_8wekyb3d8bbwe\LocalCache\Local あたりである。

従って、ランチャーのフォルダと.minecraft内の両方にmediaというフォルダを作って中にwinという名前でC:\へのジャンクション置くとうまくいく。

.minecraftの中にはゲームディレクトリ専用のフォルダを作り、その中にmain, snapshotなど用途に応じたフォルダを作っておくとよい

google-drive-ocamlfuse

labelを使うと複数アカウントをマウントできる。デフォルトのラベル名はdefault

しばらく使っていないと起動時におそらく認証の失敗が原因でマウントポイントのあるフォルダに対するlsがしばらく一切反応しなくなる(~/.gdfuse内の該当ラベル名のフォルダを削除して最初からやり直せば治る)。よってマウントポイントをホームディレクトリ直下に作るのは避けたほうがよい(gdfというフォルダを作っている)。

MEGA

Winが完全にはシャットダウンされていない状態でLinuxを起動するとCドライブ上のMEGAのフォルダが読めずに同期が無効になってしまう。MEGA自身のかわりに、Cが読める状態でのみMEGAを起動するシェルスクリプト(mega-mounted.sh)をスタートアップに登録しておく。Cが読めなかった場合にはdialogコマンドで通知ダイアログを表示する。(このスクリプトではC自身のかわりにC:\Windowsをみている)(gdialogは一部のディストリにしか入っていないかもしれない。実際にコマンド打ってみてどんな表示になるかも含めて確かめておいたほうがよい)

#!/bin/sh
if [ -d /media/win-rw/Windows ]; then
megasync
else
gdialog --title "Warning" --infobox "MEGAsync is not started because Windows partition is not mounted" 0 0
fi

Bluetooth機器

同じBluetooth機器を同じPCのWindowsとLinux双方にペアリングするというもの。自分はマウスでしかやったことがない。意外と難しいが何とかなる。

参考

  • https://orumin.blogspot.com/2019/02/bluetooth.html
  • https://qiita.com/yoko-yan/items/9b0235678fd804b4fe0d
  • Bluetooth Low Energyという仕様もあるらしく、自分のマウスはこっちだった。これに関してはhttp://aimingoff.way-nifty.com/blog/2018/09/windows-linux-b.htmlを参照。割と情報が少ないので感謝。
    • HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BTHPORT\Parameters\Keys\xxxxxxxxxxxxを見るためにpstoolsをダウンロードしてPsExec64 -s -i regeditとする必要があることに注意。なお、セキュリティソフトによってPsexecが脅威と見なされ強制削除されてしまうときは代わりにフリーソフトのAdvancedRunを使うとよい。
    • まとめ
      • CSRKをLocalSignatureKey
      • LTKをLongTermKey
      • EDIVをEdiv(16進→10進に変換)
      • ERandをRandに(バイト(2文字のかたまり)をすべて逆順にしてから10進変換)。ちなみにこれを間違えた結果、マウスを動かすたびにbluetoothアイコンが白↔黒と高速で切り替わる謎のバグっぽい現象が起こったことがあった。
      • 小文字を大文字に変える必要はない。また、IRKをIdentityResolvingKeyに書くのも不要。

マルチデバイス対応マウス(Logicool)

マルチデバイス対応(切り替えボタンがあるやつ)のマウス(LogicoolのM595)を使ったら、登録情報を一旦削除して再接続するごとにMacアドレスがひとつインクリメントされて困った。Linuxで接続→Winで接続→Linuxで上記の書き換え、とやったあと、フォルダ名を変更(1を足せばよいはずだが正確にはWinの情報を見るのがよい)するとうまくいった。自分のツイートにも記録あり