Windows 10 を使用していますが、EFI パーティションからローカル LAN ボックスと共有しているフォルダーにアクセスできません。GPT ハード ドライブがあり、その上に 1 つの巨大な「EFI システム パーティション」があります。Windows は自動的にマウントできないため、起動時にバッチ スクリプトを実行して diskpart.exe を使用し、パーティションをマウントします。このディスクからいくつかのフォルダーを共有しましたが、どの OS (Linux、Freebsd、Windows 10 自体、Android など) からもマウントできません。このフォルダーを MBR ディスクにコピーすると、共有は問題なく機能します。
これはアクセス許可の問題ではありません (アクセスが拒否されているにもかかわらず)。なぜなら、非 GPT ドライブの NTFS と共有セキュリティにまったく同じ ACL を適用し、問題なくマウントできるからです。このことから、GPT/EFI が問題であるという明らかな結論に至りました。
関連するイベントは次のとおりです。
クライアント名: \\[-scrambled-]
クライアントアドレス: [-scrambled-]:xxxxx
ユーザー名: -scrambled-\-scrambled-
セッションID: 0x980000000001D
共有名: \\*\BOOKS
共有パス: \??\X:\BOOKS
ステータス: {アクセス拒否}
プロセスがオブジェクトへのアクセスを要求しましたが、そのアクセス権が付与されていません。(0xC0000022)
マップされたアクセス: 0x100081
許可されたアクセス: 0x0*
シェアはここにあります:
-scrambled-@-scrambled-:~$ ネットシェア | grep -i books 本 X:\本
ディスクを MBR に変換できないのは、データをバックアップする方法がないからです (4TB の空き容量がありません)。MBR/GPT ディスクが混在しており、マルチブート設定がおかしいため、EFI を起動することもできません...
ご提案があれば、ぜひお聞かせください。
ありがとう！
答え1
EFI システム パーティション (ESP) に関する Wikipedia のエントリをお読みください。
https://en.wikipedia.org/wiki/EFI_システムパーティション
ESPはブートローダーと関連データを保持する場所として意図されています。ないランダムなユーザー データ (構成ファイルなど) を格納するためのものです。EFI 仕様では ESP のサイズについて明確な規定はありませんが、通常は 100 MiB から 1 GiB の間です。これより大幅に大きい場合は、適切なサイズにサイズを変更し、残りのスペースを従来の FAT または NTFS パーティションに割り当てる方がよいでしょう。ESP が 1 GiB より小さい場合は、他の場所で十分なディスク領域を見つけることができるはずです。それができない場合は、ディスクが小さすぎるため、ディスクを補充または交換する必要があります。
問題のパーティションが実際には ESP として機能しておらず、タイプ コードが不適切に設定されている可能性もあります。この場合、解決方法はタイプ コードを変更することです。私はほとんどの Windows パーティション ツールに詳しくないので、これらのツールでこのタスクを実行する方法を説明できません。Linux では、partedまたは GParted を使用してパーティションから「ブート フラグ」を削除するか、を使用してgdiskタイプ コードを EF00 からより適切なもの (パーティションが FAT または NTFS を使用している場合は 0700) に変更できます。ただし、タイプ コードを変更する前に、それが本当に ESP ではないことを確認する必要があります。ESP には と呼ばれるディレクトリがあり、そのディレクトリにはブート ローダーを保持する 1 つ以上のサブディレクトリが含まれます。Windows を起動するには、おそらくおよび/またはディレクトリ ツリーEFIがあり、少なくともそのうちの 1 つに拡張子の付いたファイルがあります。EFI\BOOTEFI\Microsoft.efi