Windows Server 2019 の共有フォルダーを全員で使わせつつ、配下の特定サブフォルダーだけ「担当者は更新可／それ以外は閲覧のみ」にしたい場面はよくあります。結論から言うと、共有権限ではなく NTFS アクセス許可（継承の制御）でサブフォルダー側に“例外”を作るのが最も確実で、運用もしやすい方法です。
やりたいことを整理：共有権限だけでは「サブフォルダー例外」を作りにくい
今回の要件は次のような状態です。
- 共有フォルダー：\\server\common（クライアントでは G: に割り当て）
- 親（common）は全員が読み取り／書き込みできる
- ただし配下の common\special だけは一部ユーザーのみ更新可、それ以外は閲覧のみ
Windows のファイル共有では、アクセス可否は基本的に「共有（Share）権限」と「NTFS 権限」の両方で評価され、より厳しい（制限が強い）ほうが最終結果になります。サブフォルダー単位で細かく差を付けたい場合、実質的に主役は NTFS 権限です。
| 項目 | 共有（Share）権限 | NTFS 権限 |
|---|---|---|
| 適用範囲 | 共有名（\\server\common）単位 | フォルダー／サブフォルダー／ファイル単位 |
| 得意なこと | 「この共有に入れる人」を大枠で制御 | 「このサブフォルダーは更新可／閲覧のみ」など細分化 |
| 運用の定石 | 広めに付与（変更可など） | 細かい制御はここで行う（継承・グループ設計） |
| 今回の結論 | 共通利用できるよう“広め”でOK | special で継承を止め、権限を作り替える |
最初に決めると失敗しない：セキュリティグループで管理する
ユーザー個別に権限を付けると、増減のたびに ACL が肥大化し、誰がどこまでできるのか追えなくなります。Active Directory 環境ならセキュリティグループで整理するのが鉄板です（ドメイン参加していない場合はローカルグループでも考え方は同じ）。
| グループ例 | 用途 | 対象 |
|---|---|---|
| Common_RW | \\server\common 全体を更新できる | 共有を使う全ユーザー |
| Special_RW | common\special を更新できる | 担当者・限られたユーザー |
| Special_RO | common\special を閲覧のみ | 担当者以外（＝ほぼ全員） |
ポイントは、special の “更新できる人” と “閲覧だけの人” を明確に分けることです。「担当者以外」は人数が多くなりがちなので、Special_RO を “全員グループ” に寄せる（例：Common_RW を閲覧用として使う、または Authenticated Users を閲覧に使う）と運用が軽くなります。
推奨の基本設計：共有権限は広め、例外は NTFS で作る
今回の要件を最もシンプルに満たす考え方はこれです。
- 共有（\\server\common）の権限：Common_RW に「変更」（または必要に応じて「フルコントロール」）
- NTFS（フォルダーのセキュリティ）：common 直下は Common_RW を更新可
- NTFS（special）：継承を無効化して、Special_RW は更新可／Special_RO は閲覧のみ
共有権限で無理に頑張らない理由は明確で、共有権限は共有名単位のため、同じ共有の中でサブフォルダーだけルールを変えるなら NTFS が本体だからです。
手順：親は広く許可し、special だけ例外にする（GUI での設定）
サーバー側の前提：実体フォルダーを確認する
共有パス（\\server\common）は“共有名”であり、サーバー上には実体フォルダーが存在します。例として以下のように説明します。
- 実体フォルダー：D:\Shares\Common
- 共有名：common（\\server\common）
- サブフォルダー：D:\Shares\Common\Special
共有権限（\\server\common）の設定：細かい制御は NTFS に寄せる
共有権限は“入口”です。ここで厳しくしすぎると、special の担当者も含めて全体が動かなくなりがちです。まずは次のような構成が扱いやすいです。
| 主体 | 共有権限（推奨例） | 狙い |
|---|---|---|
| Administrators | フルコントロール | 管理・復旧・監査 |
| SYSTEM | フルコントロール | OS／サービス動作用 |
| Common_RW（または Authenticated Users） | 変更 | 共有へアクセスする全員の入口 |
共有権限は「詳細な共有」→「アクセス許可」で設定します。もし既に「Everyone: フルコントロール」になっていても、NTFS で締めれば動作上は成立しますが、監査や意図しない公開範囲の観点では“誰でも”を残さないほうが安全です。
親フォルダー（Common）の NTFS 権限：全員更新可の土台を作る
次に、実体フォルダー（D:\Shares\Common）の「プロパティ」→「セキュリティ」で NTFS 権限を整えます。親は全員読み書きできる前提なので、ここはシンプルでOKです。
| 主体 | NTFS 権限（推奨例） | 適用先 |
|---|---|---|
| SYSTEM | フルコントロール | このフォルダー、サブフォルダーおよびファイル |
| Administrators | フルコントロール | このフォルダー、サブフォルダーおよびファイル |
| Common_RW | 変更（Modify） | このフォルダー、サブフォルダーおよびファイル |
| （任意）CREATOR OWNER | サブフォルダーとファイルの変更 | サブフォルダーとファイルのみ |
「変更（Modify）」を使う理由は、読み取り＋書き込み＋削除まで含み、共有利用で不足しにくいからです。一方「フルコントロール」は権限変更や所有権取得までできるため、一般ユーザーに付けると事故が起きやすくなります。
Special の NTFS 権限：継承を止めて“例外ルール”に作り替える
ここが本題です。D:\Shares\Common\Special（= common\special）の権限を、親からの継承ベースから special 専用に再構成します。
- Special を右クリック → プロパティ → セキュリティ → 詳細設定 を開きます。
- 「継承の無効化」をクリックします。
- 表示される選択肢は環境により文言が多少異なりますが、基本は 「継承されたアクセス許可をこのオブジェクト上の明示的なアクセス許可に変換（Convert）」 を選びます。
- Convert を選ぶと、現状の ACL を“土台”として編集でき、事故が少なくなります。
- Convert 後、Special の一覧には親由来のエントリが明示的に並びます。ここから special の要件に合わせて整理します。
- Common_RW（全員更新可）を Special から外す（または権限を「読み取り」に落とす）
- Special_RW を追加して「変更（Modify）」
- Special_RO を追加して「読み取りと実行（Read & Execute）」
- SYSTEM／Administrators はフルコントロールのまま維持
- 各エントリの「適用先」が意図通りか確認します。基本は次の形にするとトラブルが減ります。
| 主体 | Special の NTFS 権限（推奨例） | 適用先 |
|---|---|---|
| SYSTEM | フルコントロール | このフォルダー、サブフォルダーおよびファイル |
| Administrators | フルコントロール | このフォルダー、サブフォルダーおよびファイル |
| Special_RW | 変更（Modify） | このフォルダー、サブフォルダーおよびファイル |
| Special_RO | 読み取りと実行（Read & Execute） | このフォルダー、サブフォルダーおよびファイル |
これで、同じ \\server\common の配下にありながら、Special だけ “担当者は更新可／それ以外は閲覧のみ” の挙動になります。共有経由（G: でも UNC でも）でアクセスしても、最終的には NTFS 権限が効くため、意図した制御が実現できます。
「拒否（Deny）」を使わずに実現するのが安全な理由
「閲覧のみ」を作るときに、つい「書き込みを拒否」にしたくなりますが、Deny は運用トラブルの原因になりがちです。
- ユーザーが複数グループに所属していると、意図せず Deny が勝ってしまう
- フォルダー階層が深くなるほど、どこで Deny されたか追いにくい
- 管理者の復旧作業でも足を引っ張ることがある
基本方針はシンプルで、書き込み系の「許可」を付けない（または外す）だけで「閲覧のみ」は作れます。どうしても“絶対に禁止”が必要な場合のみ Deny を検討し、まずは許可設計で解決するのが無難です。
設定後の確認：Effective Access と実機テストをセットで行う
Effective Access（実効アクセス）でユーザーごとの結果を確認
Special の「セキュリティ」→「詳細設定」には、ユーザー／グループを指定して“実際に何ができるか”を確認できる機能があります（環境により「実効アクセス」「有効なアクセス」等の表記）。
- Special_RW のユーザー：作成・編集・削除が可能になっているか
- Special_RO のユーザー：読み取りはできるが、作成・編集・削除が不可になっているか
クライアント PC での実機テスト（G: ドライブでも確認）
机上の ACL が正しくても、クライアント側の接続状態で「思ったのと違う」ことがあります。最低限、次を確認します。
- Special_RW でサインイン → G:\Special にファイル作成／編集／削除ができる
- Special_RO でサインイン → G:\Special の閲覧はできるが、作成／編集／削除ができない
もし別ユーザーの検証で挙動が混ざる場合は、Windows が SMB セッションを保持している可能性があります。テスト時だけでも一度切断して再接続すると切り分けが早くなります。
net use net use g: /delete net use \\server\common /delete
よくあるつまずきと解決策（現場で効くチェックポイント）
Special_RO なのに書き込みできてしまう
原因の多くは「Special に、全員更新可の権限が残っている」ことです。
- Special で継承を無効化したつもりが、実は継承のまま
- Convert 後に、Common_RW（または Everyone/Authenticated Users）へ変更（Modify）が残っている
- ユーザーが Special_RW を含む別グループにも所属している（特に兼務者）
対策は、Special の ACL を開いて「誰に Modify/Write が付いているか」を見える化し、Special_RO には Read & Execute のみになるよう整理することです。
Special_RW なのに更新できない（アクセスが拒否される）
「共有権限は OK だと思っていたが、共有側が厳しくて止まっていた」というパターンがあります。共有権限と NTFS 権限は両方評価されるため、片方が Read だと最終的に Read になります。
- 共有権限で Special_RW（または Common_RW）に「読み取り」しか付いていない
- 共有権限で対象ユーザーがそもそも入れていない
共有権限は“入口”として広め（変更）にし、制御は NTFS で行う設計に戻すと安定します。
作成はできるのに削除だけできない／名前変更ができない
「細かい権限をカスタムで付けた結果、Delete 系が抜けた」ことで起きやすい症状です。基本は built-in の「変更（Modify）」を使うと不足しにくいです。既にカスタム化している場合は、Special_RW に以下が含まれているか確認します。
- 削除（Delete）
- サブフォルダーとファイルの削除（Delete subfolders and files）
special を別共有に切り出したのに、\\server\common 経由で入れてしまう
「\\server\special を作れば安心」と考えがちですが、同じ実体フォルダー／同じファイルシステム上の場所であれば、別の共有名から到達できる可能性は残ります。つまり、共有名を増やしても最終的な防波堤は NTFS 権限です。
今回の要件（閲覧は許可、更新だけ制御）でも同じで、どの共有経路から来ても、Special の NTFS で “更新できる人／できない人” を確定させるのが確実です。
「見せたくない」までやりたい場合（応用）
要件が「閲覧のみ」ではなく「そもそも見せない」なら、Special_RO に Read を与えず、アクセス権がない状態にします。そのうえで、フォルダー一覧から見えなくするには「アクセス ベースの列挙（Access-Based Enumeration）」も有効です。ただし ABE は“権限がないものを列挙しない”仕組みなので、閲覧権限を付けた時点で見える点には注意してください。
コマンドで確認・自動化したい場合（icacls の例）
GUI での設定が基本ですが、サーバー台数が多い／同じ構成を何度も作る場合は、権限をコマンドで確認できると管理が楽です。
現在の権限を確認
icacls "D:\Shares\Common\Special"
継承を無効化（Disable）
継承の扱いは状況により選び方が変わるため、実行前にバックアップやテストを推奨します。
icacls "D:\Shares\Common\Special" /inheritance:d
権限を付与（例：Special_RW に Modify、Special_RO に Read & Execute）
icacls "D:\Shares\Common\Special" /grant "DOMAIN\Special_RW:(OI)(CI)M" icacls "D:\Shares\Common\Special" /grant "DOMAIN\Special_RO:(OI)(CI)RX"
補足として、(OI) はファイルへの継承、(CI) はサブフォルダーへの継承を意味します。M は Modify、RX は Read & Execute です。
運用をラクにする小技：権限設計を「増やさない」
現場で権限が荒れやすい原因は、例外が増えることです。special の運用が長期化するほど、次の工夫が効いてきます。
- 役割が増えたらグループを増やす（ユーザーに直付けしない）
- 「Special_RW に入れる＝更新できる」という業務ルールを文書化しておく
- ACL をいじる担当者を限定し、変更履歴を残す（チケット・変更管理）
- 監査が必要なら、オブジェクトアクセス監査（監査ポリシー＋フォルダー監査）も併用する
まとめ：サブフォルダー例外は「継承を止めて NTFS で作り替える」が最短ルート
Windows Server 2019 の共有フォルダーで「親は全員更新可、特定サブフォルダーだけ一部ユーザー更新可／それ以外閲覧のみ」を実現するなら、答えは一貫してspecial 側の NTFS アクセス許可です。
- 共有権限は入口として広め（変更）にする
- special で継承を無効化し、special 専用の ACL に組み替える
- “拒否”ではなく、“書き込み許可を付けない”で RO を作る
- Effective Access と実機テストで最後まで確認する
この設計にしておけば、将来 special が増えても同じパターンで安全に横展開できます。まずは special 1つで型を作り、グループ運用に乗せるところから始めるのがおすすめです。
コメント