デュアルブート - 版の履歴

Turgenev: Notion-MW

2025-10-02T06:09:16Z

Notion-MW

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

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

	また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。		また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる（実行権限を外すと.exeなどが実行できなくなる）。従って、GitのレポジトリのフォルダをWindows/Linux間で共用するようなことをすると、Windows側では実行権限無しで（これがデフォルトであるため）コミットされたファイルがLinux側では実行権限有りに見えるため差分が出てしまうといったことが発生する。これはUserMappingでも解決はできないので、Gitリポジトリのあるフォルダを共用するのは不可能である。
99行目:		99行目:
	<syntaxhighlight lang="javascript">map=root/myname:@root/@myname,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore</syntaxhighlight></li></ul>		<syntaxhighlight lang="javascript">map=root/myname:@root/@myname,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore</syntaxhighlight></li></ul>
	</li>		</li>
	<li><p>~~Gitのようにパーミッションを変更できる必要があるものは、改めてこれも別のbindfsとして再マウントする。~~</p></li>		<li><p>Gitのようにパーミッションを変更できる必要があるものは、改めてこれも別のbindfsとして再マウントする。この場合、Windows側からはアクセスの問題が生じる可能性があるので、とりあえず内容だけ確認したいときに見られればいいという状況で使うのがいいだろう。</p></li>
	<li><p>あるいはbindfsを1つにまとめてcreate-with-perms=+rw（xは指定しない）にするのもいけるかもしれないが、本当にうまくいくかどうか…</p></li></ul>		<li><p>あるいはbindfsを1つにまとめてcreate-with-perms=+rw（xは指定しない）にするのもいけるかもしれないが、本当にうまくいくかどうか…</p></li>
			<li><p>設定例</p></li></ul>

			<syntaxhighlight lang="javascript">UUID=109B0ED0109B0ED0 /media/localdisk ntfs-3g permissions,nofail 0 0
			UUID=040CAEB80CAEA460 /media/cdrive ntfs-3g permissions,nofail,remove_hiberfile 0 0
			/media/localdisk /home/useruser/.mnt/localdisk2 fuse.bindfs nofail,map=root/useruser:@root/@useruser,create-with-perms=g-w 0 0
			/media/localdisk /home/useruser/.mnt/localdisk fuse.bindfs nofail,map=root/useruser:@root/@useruser,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore 0 0
			/media/cdrive /home/useruser/.mnt/cdrive2 fuse.bindfs nofail,map=root/useruser:@root/@useruser,create-with-perms=g-w 0 0
			/media/cdrive /home/useruser/.mnt/cdrive fuse.bindfs nofail,map=root/useruser:@root/@useruser,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore 0 0</syntaxhighlight>
	==== bindfs ====		==== bindfs ====

133行目:		140行目:

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

			ちゃんと設定されていれば、実体フォルダは必ずしもRoaming以下の階層になければならないわけではない。

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

Turgenev: Notion-MW

2025-09-01T01:32:05Z

Notion-MW

← 古い版		2025年9月1日 (月) 10:32時点における版
80行目:		80行目:
	Windowsに挙動を近づけるための他のオプションとしては<strong>inherit</strong>というのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは<u>所有者を継承するオプションではない</u>（そして、所有者が違えばまともに継承もされない）。		Windowsに挙動を近づけるための他のオプションとしては<strong>inherit</strong>というのもあり、これは新規作成時に上位フォルダの権限を継承するものである。しかし、これは<u>所有者を継承するオプションではない</u>（そして、所有者が違えばまともに継承もされない）。

	* [https://github.com/tuxera/ntfs-3g/issues/90 https://github.com/tuxera/ntfs-3g/issues/90] ~~では、UserMappingがなくても所有者が継承されるようになるパッチが示されているが、これを使うとpermissionsは動かなくなる（chmodなどが使えない）。~~		* [https://github.com/tuxera/ntfs-3g/issues/90 https://github.com/tuxera/ntfs-3g/issues/90] では、UserMappingがなくても所有者が継承されるようになるパッチが示されているが、これを使うとpermissionsは動かなくなる（chmodなどが使えない）。自力で変えようとしてみたが、うまくいかなかった。

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

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

			結局、後述のbindfsと組み合わせると、以下のようにするのが良さそう。

			<ul>
			<li><p>大元のntfsパーティションは、permissionsでマウント。UserMappingを使ってもよい。</p></li>
			<li><p>Linux側でパーミッションを変更できる必要がなく、Windows側と共用したいものについては、bindfsで再マウントし、create-with-perms=a+rwxによってWindows側でアクセスに制約が出ないようにする。</p>
			<ul>
			<li><p>より完全なオプションとしては、以下のような感じ？</p>
			<syntaxhighlight lang="javascript">map=root/myname:@root/@myname,perms=a+rwx,create-with-perms=a+rwx,chown-ignore,chgrp-ignore,chmod-ignore</syntaxhighlight></li></ul>
			</li>
			<li><p>Gitのようにパーミッションを変更できる必要があるものは、改めてこれも別のbindfsとして再マウントする。</p></li>
			<li><p>あるいはbindfsを1つにまとめてcreate-with-perms=+rw（xは指定しない）にするのもいけるかもしれないが、本当にうまくいくかどうか…</p></li></ul>

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

Turgenev: Notion-MW

2025-06-30T09:02:46Z

Notion-MW

← 古い版		2025年6月30日 (月) 18:02時点における版
79行目:		79行目:

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

			* [https://github.com/tuxera/ntfs-3g/issues/90 https://github.com/tuxera/ntfs-3g/issues/90] では、UserMappingがなくても所有者が継承されるようになるパッチが示されているが、これを使うとpermissionsは動かなくなる（chmodなどが使えない）。

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

Turgenev: Notion-MW

2025-06-03T13:39:59Z

Notion-MW

← 古い版		2025年6月3日 (火) 22:39時点における版
97行目:		97行目:
	<syntaxhighlight lang="python">sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>		<syntaxhighlight lang="python">sudo bindfs --force-user=myname --force-group=myname /media/win ~/.mnt_win/</syntaxhighlight>
	この2つの違いは不明		この2つの違いは不明

			作成した

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

Turgenev: Notion-MW

2025-05-05T01:30:35Z

Notion-MW

← 古い版		2025年5月5日 (月) 10:30時点における版
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-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2]		ntfs-3gの前にDislockerで暗号化を解除する。参考→[http://www7390uo.sakura.ne.jp/wordpress/archives/270 http://www7390uo.sakura.ne.jp/wordpress/archives/2]
63行目:		63行目:
	recovery-passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。		recovery-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://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] ~~ここに書いてある。~~		[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] 詳しくはこちらも参照。

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

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

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

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

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

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

	~~<code>~~-~~o uid~~=~~$(id~~ -~~u),gid~~=~~$(id~~ -~~g)<~~/code>とする。ただしこれだと複数ユーザーで使えない。複数ユーザーで使うときは、UserMappingを使用する（WindowsでのユーザーとLinuxでのユーザーを対応づけたい場合はこちら）か、bindfsを使うとよい。（一旦rootでマウントしてから、各ユーザー向けにそのユーザーの権限でマウント）		以上のことから、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 ====		==== 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>

Turgenev: Notion-MW

2024-11-22T16:19:36Z

Notion-MW

← 古い版		2024年11月23日 (土) 01:19時点における版
83行目:		83行目:
	==== 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>

Turgenev: Notion-MW

2024-10-09T07:23:28Z

Notion-MW

← 古い版		2024年10月9日 (水) 16:23時点における版
17行目:		17行目:
	* Bitlockerを有効にしたあとにwinを起動すると再起動ループにハマることがある。解決法(Manage-bdeを使う)→[https://community.spiceworks.com/how_to/124388-stop-a-bitlocker-boot-loop Stop a BitLocker boot loop - Windows Forum - Spiceworks]		* Bitlockerを有効にしたあとにwinを起動すると再起動ループにハマることがある。解決法(Manage-bdeを使う)→[https://community.spiceworks.com/how_to/124388-stop-a-bitlocker-boot-loop Stop a BitLocker boot loop - Windows Forum - Spiceworks]

	<span id="~~windowsパーティションのマウント~~"></span>		<span id="windowsパーティションntfsのマウント"></span>
	== ~~Windowsパーティションのマウント~~ ==		== Windowsパーティション（NTFS）のマウント ==

	{{Outdated}}		{{Outdated}}
56行目:		56行目:
	<p>と、二行に分けて記載する。</p>		<p>と、二行に分けて記載する。</p>
	<ul>		<ul>
	<li>permissions ~~ってどういう意味だっけ~~</li></ul>		<li>permissions については後述</li></ul>
	</li></ul>		</li></ul>

62行目:		62行目:

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

			=== permissionsについて ===

			[https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions https://github.com/tuxera/ntfs-3g/wiki/File-Ownership-and-Permissions] ここに書いてある。

			NTFSでのパーミッションの扱いとPOSIXでのパーミッションの扱いがかなり異なるため、WindowsとLinuxでパーティションをうまく共用するのは（特に各ユーザーフォルダ内に関しては）難しい。

			まず、ntfs-3gでUserMappingを指定しない限りは、Linux上で新規作成したファイルは全てAdministratorsの所有物になる。また、特に指定がない限りはそれらのアクセス権はEveryoneがフルコントロールできる状態になる。もちろん親フォルダのアクセス権がなければ見えてしまうことはないが、エクスプローラー上でも周りのファイルとは明確にアクセス権がズレてしまう。なお、inheritオプションを使って上位フォルダの権限を継承することはできるが、所有者が違えばまともに継承もされないのであまり意味がない。

			また、Windowsではファイルの新規作成時には必ず実行権限が付加されるので、Linux側でそれを見た場合も実行可能になる。（実行権限を外すと.exeなどが実行できなくなる）

			したがって、少なくともntfs-3gにちゃんとしたUserMappingを与えない限りは、各ユーザーフォルダに作成したファイルを自動的にそのユーザーの所有物にするようなことは不可能である。

	=== 特定ユーザーとしてmount ===		=== 特定ユーザーとしてmount ===
94行目:		106行目:

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

			* ストアアプリ版の（新しい方の？）Minecraftランチャーでは、この「ランチャーがあるフォルダ」は<code>AppData\Local\Packages\Microsoft.4297127D64EC6_8wekyb3d8bbwe\LocalCache\Local</code> あたりである。

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

Turgenev: Notion-MW

2024-05-19T12:56:09Z

Notion-MW

← 古い版		2024年5月19日 (日) 21:56時点における版
67行目:		67行目:
	[https://ikb.hatenablog.com/entry/20110203/1296725898 https://ikb.hatenablog.com/entry/20110203/1296725898]のように		[https://ikb.hatenablog.com/entry/20110203/1296725898 https://ikb.hatenablog.com/entry/20110203/1296725898]のように

	<code>-o uid=$(id -u),gid=$(id -g)</code>とする。ただしこれだと複数ユーザーで使えない。複数ユーザーで使うときは、bindfsを使うとよい。（一旦rootでマウントしてから、各ユーザー向けにそのユーザーの権限でマウント）		<code>-o uid=$(id -u),gid=$(id -g)</code>とする。ただしこれだと複数ユーザーで使えない。複数ユーザーで使うときは、UserMappingを使用する（WindowsでのユーザーとLinuxでのユーザーを対応づけたい場合はこちら）か、bindfsを使うとよい。（一旦rootでマウントしてから、各ユーザー向けにそのユーザーの権限でマウント）

	==== bindfs ====		==== bindfs ====
83行目:		83行目:
	fstabの例		fstabの例

	<syntaxhighlight lang="python">/media/win /home/myname/.mnt_win fuse.bindfs nofail,~~force-user~~=myname,~~force~~-~~group=myname,~~perms=~~700~~ 0 0</syntaxhighlight>		<syntaxhighlight lang="python">/media/win /home/myname/.mnt_win fuse.bindfs nofail,map=root/myname:@root/@myname,create-with-perms=g-w 0 0</syntaxhighlight>
			Linuxだとrootのデフォルトのumaskが022で一般ユーザーが002なせいで一般ユーザーが作ったファイルが775とか664になってしまったりするがg-wをつけることによって755とか644になる（もちろんchmodすれば変えられる

	<span id="minecraft"></span>		<span id="minecraft"></span>
	== Minecraft ==		== Minecraft ==

Turgenev: Notion-MW

2024-04-01T02:08:20Z

Notion-MW

@@ 63行目: / 63行目: @@
 recovery&#45;passwordを暗号化されていないパーティションに書いてしまうと結局Bitlockerの意味が全くなくなってしまうので、Linux側でもBitlockerのような暗号化パーティション（LUKSとか？）やユーザーログイン時に復号される暗号化フォルダ（ecryptfsとか）といったディスク上で暗号化される領域に書いておく必要がある（もちろん毎回パスワードの類を打ち込むのでよければそれでもいい）。
 <span id="minecraft"></span>
 == Minecraft ==

Turgenev: Notion-MW

2024-01-25T10:05:56Z

Notion-MW

← 古い版		2024年1月25日 (木) 19:05時点における版
61行目:		61行目:
	==== セキュリティ問題 ====		==== セキュリティ問題 ====

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

	~~{{Stub}}~~

	<span id="minecraft"></span>		<span id="minecraft"></span>