TipsWindows

共有フォルダで「フルコントロールにしたのに書けない」ときに見る2つの権限

スポンサーラベル
共有フォルダの権限は共有のアクセス許可とNTFSのアクセス許可の2層で、厳しいほうが適用される。ローカルログオン時はNTFSのみが効く Tips

当サイトはアフィリエイト広告を利用しています。

共有フォルダに書き込めないという問い合わせを受けて、Everyoneにフルコントロールを与えたのに、まだ書けない。情報システム部門に配属されて最初の数ヶ月で、多くの人がここで止まります。

原因はたいてい、権限が2層あることを知らずに片方だけ直していることです。さらに、フルコントロールを持っていても拒否が1つあるだけで負けるという規則もあります。

共有フォルダの権限は共有のアクセス許可とNTFSのアクセス許可の2層で、厳しいほうが適用される。ローカルログオン時はNTFSのみが効く

この記事では、2つの権限の関係と、確認に使うコマンドを整理します。検証は Windows 11 Pro で行いました。

1. 結論:権限は2層あり、厳しいほうが勝つ

共有フォルダにネットワーク越しにアクセスすると、2つの関門を順に通ります。

層設定場所効く場面
共有のアクセス許可フォルダのプロパティ → 共有 → 詳細な共有 → アクセス許可ネットワーク越しのときだけ
NTFSのアクセス許可フォルダのプロパティ → セキュリティ常に(ローカルでもネットワークでも)

最終的な権限は、この2つの厳しいほうになります。片方をフルコントロールにしても、もう片方が読み取り専用なら読み取り専用のままです(この規則は公式ドキュメントに基づくもので、本記事では実機での再現は行っていません。実測したのは3章以降です)。

つまり「フルコントロールにしたのに書けない」は、たいてい直した側と違うほうが効いているという話です。

2. 定石は「共有側を開けて、NTFSで絞る」

実務では次の形が定番です。

  • 共有のアクセス許可 … Everyone にフルコントロール
  • NTFSのアクセス許可 … 実際に使わせたいグループにだけ必要な権限

理由は単純で、管理する場所を1か所にまとめるためです。2層とも細かく設定すると、権限を変えるたびに両方を見る必要があり、片方の直し忘れが起きます。厳しいほうが勝つので、共有側を開けておいてもNTFS側で絞れば安全は保たれます。

ここで驚かないでほしいのですが、共有側が Everyone フルコントロールになっているのは、多くの場合は設定ミスではありません。意図的にそうしている構成です。確認するときはNTFS側を見てください。

逆に「共有側で絞る」運用も不可能ではありませんが、ローカルログオンした利用者やリモートデスクトップ経由の利用者には共有のアクセス許可が効かないため、抜け道が残ります。

3. 拒否は許可に勝つ(実測)

もうひとつの落とし穴が拒否(Deny)です。フルコントロールを持っていても、拒否が1つあれば負けます。

実際に試します。まずフォルダを作ると、親から権限が継承されます。

# 作りたてのフォルダの権限を見る
icacls C:\test
C:\test NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
        BUILTIN\Administrators:(I)(OI)(CI)(F)
        PC01\yamada:(I)(OI)(CI)(F)

(I) が継承されたという印、(F) がフルコントロールです。この時点で yamada はフルコントロールを持っています。

ここに読み取りの許可と、書き込みの拒否を足します。

icacls C:\test /grant "PC01\yamada:(OI)(CI)(RX)"
icacls C:\test /deny  "PC01\yamada:(OI)(CI)(W)"
icacls C:\test
C:\test PC01\yamada:(OI)(CI)(DENY)(W)      ← 明示的な拒否
        PC01\yamada:(OI)(CI)(RX)           ← 明示的な許可
        NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
        BUILTIN\Administrators:(I)(OI)(CI)(F)
        PC01\yamada:(I)(OI)(CI)(F)         ← 継承されたフルコントロール

同じユーザーに対して、継承のフルコントロールと明示的な拒否が同居している状態です。この状態で書き込むとどうなるか。

Set-Content C:\test\x.txt "test"
Set-Content : Access to the path 'C:\test\x.txt' is denied.

拒否されました。 フルコントロールを持っていても、拒否が1つあれば書けません。

「権限を足したのに効かない」ときは、足した権限ではなく、どこかに付いている拒否を探してください。 拒否を外すと、同じ操作が通ります。

4. 明示と継承を見分ける

前節の出力で重要なのは (I) の有無です。

  • (I) がある … 親フォルダから継承されたもの。そのフォルダでは直せない(親を直すか、継承を切る)
  • (I) がない … そのフォルダに直接付いているもの

並び順にも意味があり、明示的なものが先、継承されたものが後に表示されます。

継承を切ると、継承されていた権限がそのフォルダ自身の権限として固定されます。

# 継承を切る(それまでの継承分はコピーされて残る)
icacls C:\test /inheritance:d

実行後は (I) が消えます。以後、親フォルダの権限を変えてもこのフォルダには波及しません。

トラブル対応でよくあるのが、ここを切ったまま忘れられているケースです。親で権限を直したのに反映されない場合は、(I) が付いているかを先に確認してください。

5. 権限を確認するコマンド

画面をたどらずに確認できると調査が速くなります。

NTFS側

icacls C:\test                       # 一覧をそのまま見る
(Get-Acl C:\test).Access | Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited

Get-Acl のほうは IsInherited の列で継承かどうかが True / False で出るので、(I) を読むのが面倒なときに便利です。

共有側

Get-SmbShare                                     # 共有の一覧
Get-SmbShareAccess -Name "Share"                 # 共有のアクセス許可
Name  AccountName             AccessControlType AccessRight
----  -----------             ----------------- -----------
Share BUILTIN\Administrators              Allow        Full
Share Everyone                            Allow        Full

この2つを並べて見るのが、切り分けの最短経路です。 片方だけ見ている限り、原因には辿り着きません。

なお Get-SmbShare と Get-SmbShareAccess は参照だけなら管理者権限なしでも実行できます(実測)。調査の段階では昇格しなくて済みます。

6. 共有を作るには「管理者アカウント」では足りない

最後に、初心者がつまずくもうひとつの点です。

共有を作成・変更するには昇格した権限が必要です。管理者アカウントでログオンしているだけでは足りません。 通常のPowerShellから実行すると、こうなります。

New-SmbShare -Name "test" -Path "C:\test" -FullAccess "Everyone"
New-SmbShare : アクセスが拒否されました。
    + FullyQualifiedErrorId : Windows System Error 5,New-SmbShare

管理者アカウントであっても、UACによって通常の操作では制限されたトークンが使われるためです。PowerShellを右クリックして「管理者として実行」で開き直す必要があります。

自分が昇格しているかは次で確認できます。

$id = [Security.Principal.WindowsIdentity]::GetCurrent()
(New-Object Security.Principal.WindowsPrincipal($id)).IsInRole(
    [Security.Principal.WindowsBuiltInRole]::Administrator)
# True なら昇格している

スクリプトに組み込むなら、この判定を冒頭に置いて、昇格していなければ止めるのが安全です。 昇格せずに走らせると、権限エラーが「設定が効いている」ように見えてしまい、調査を誤ります。

7. まとめ

共有フォルダの権限で詰まったときに見る順番を整理します。

  • 権限は2層。 共有のアクセス許可とNTFSのアクセス許可があり、厳しいほうが適用される
  • 共有側は Everyone フルコントロールが定石。 設定ミスとは限らないので、NTFS側を見る
  • ローカルログオン時は共有のアクセス許可が効かない。 NTFSだけが効く
  • 拒否は許可に勝つ。 フルコントロールを持っていても、拒否が1つあれば負ける
  • (I) は継承の印。 付いていればそのフォルダでは直せない
  • 確認は icacls と Get-SmbShareAccess を並べて見る

「フルコントロールにしたのに書けない」の大半は、この6点のどれかで説明が付きます。画面を往復する前に、2つのコマンドを並べて叩いてみてください。

根拠について

本記事の内容は、次のように根拠が分かれています。

内容根拠
拒否が許可に勝つ(3章)実測(Windows 11 Pro)
継承の (I) と継承の切り方(4章)実測
確認コマンドと、参照は非管理者でも可(5章)実測
昇格しないと共有を作れない(6章)実測
2層が「厳しいほう」で決まる規則(1〜2章)Microsoft の公式ドキュメント準拠。本記事では実機で再現していません

掲載しているコマンド出力は実際に取得したものです(ユーザー名は伏せています)。

コメント

タイトルとURLをコピーしました