Windows Server 2019 の共有フォルダーへ SQL ジョブから書き込もうとして Access Denied。共有権限は触っていないのに、エクスプローラーの［セキュリティ］で NTFS 権限を追加したら直った――この現象は「共有権限と NTFS 権限のどちらが本当に詰まっていたか」を見誤りやすいのが原因です。仕組みと切り分け方を、現場で再現できる手順つきで整理します。
まず結論：ルールは「共有権限 × NTFS権限」だが、ボトルネックは片方だけとは限らない
Windows の共有フォルダー（SMB 共有）で、UNC パス（例：\\myserver\mydatafolder\）にアクセスする場合の基本ルールは変わりません。
| 項目 | 効く場面 | よくある誤解 | 正しい理解 |
|---|---|---|---|
| 共有権限（Share） | ネットワーク経由（UNC / SMB） | 「セキュリティタブで見える」 | 共有の設定画面（共有のアクセス許可）で見る |
| NTFS 権限 | ローカル・ネットワーク両方（対象フォルダー上） | 「共有権限より後回し」 | 共有が広ければ、実質 NTFS が主役になる |
| 実効権限 | UNC アクセス時 | 「共有か NTFS のどちらか」 | 共有権限と NTFS 権限の“より厳しい方”（積集合） |
つまり「共有権限も NTFS も両方必要」は正しい一方で、今回のように NTFS を直しただけで解決するケースは珍しくありません。それは、共有権限が実は通っていた（または共有を通っていなかった）可能性が高いからです。
「共有権限を触っていないのに、NTFS だけ直したら動いた」よくある原因
共有権限が“思っているほど厳しくない”
運用として最も多いのがこのパターンです。共有権限は広め（例：Authenticated Users / Everyone に変更権限など）にして、実際のアクセス制御は NTFS で行う方式です。
この場合、共有権限側は最初から通っているので、書き込みに失敗する原因は NTFS 側に集中します。NTFS に mydomain\jobuser（または所属グループ）を追加した瞬間に通るのは自然な挙動です。
| 共有権限の運用例 | メリット | 注意点 |
|---|---|---|
| 共有：Authenticated Users = 変更、Administrators = フル | 共有での詰まりが減り、NTFS で一元管理しやすい | NTFS を適切に絞らないと“広く書ける”状態になる |
| 共有：Everyone = フル、NTFS で厳密に制御 | トラブルシュートが楽（共有で落ちにくい） | 「共有がフル」だけ見て誤解されやすい。監査・説明が必要 |
| 共有：グループごとに細かく制御（共有も NTFS も厳密） | 多層防御になる | 設計が複雑化しやすく、変更時に事故が起きやすい |
なお、エクスプローラーの［セキュリティ］タブで見ているのは NTFS 権限 です。「Administrators のみ」に見えたのがセキュリティタブの内容であれば、それは共有権限の話ではありません。
SQL ジョブが“共有（UNC）”ではなく“ローカルパス”へ書いていた
これも非常に多い落とし穴です。ジョブの「パス文字列」は \\server\share のように見えていても、実際の処理（スクリプトやツール）がローカルパスを参照していることがあります。たとえば次のようなケースです。
- ジョブステップが
D:\mydatafolder\に出力する（共有は同じフォルダーを指しているだけ） - バッチや PowerShell の中でローカルパスに組み立て直している
- バックアップやエクスポート処理が「サーバー上のローカルディスク」に吐いている
ローカルパスに書く場合、共有権限は評価されません。したがって NTFS だけ直せば動きます。特に「SQL Server/SQL Agent が同じサーバー上で動いている」構成だと、このパターンが混ざりやすいです。
確認ポイントは単純で、ジョブステップに書かれているパス（文字列）だけでなく、実際に実行されるコマンドやスクリプトの中身まで見ることです。
jobuser が共有権限を“グループ経由”で既に持っていた
共有権限はユーザー直付けだけでなく、AD グループの許可が普通に効きます。よくある例は次のとおりです。
Domain UsersやAuthenticated Usersに共有の許可が付いていた- 運用グループ（例：
FileShare_Change）にjobuserが所属していた - 別名の共有（別 share name）では広い共有権限だった
この場合、共有は最初から通っていて、詰まっているのは NTFS だけです。「共有権限は Administrators のみ」に見えたという状況でも、次のような取り違えが起きがちです。
| 起きがちな取り違え | どうして起きる？ | 防ぐコツ |
|---|---|---|
| 見ていたのが “共有” ではなく “NTFS（セキュリティタブ）” だった | UI が似ていて「権限＝ここ」と思い込む | 共有は［共有］→［詳細な共有］→［アクセス許可］で確認する |
| 同じフォルダーが複数の共有名で公開されていた | 過去の設定が残る。移行時に増える | net share / Get-SmbShare で共有名とパスを突き合わせる |
| DFS 名前空間を経由しており、見ている共有が違う | アクセスは DFS、確認はサーバー直の共有 | 実際にアクセスしている UNC をそのまま起点に辿る |
「実行アカウントが jobuser」のつもりでも、実際は別アカウントで動いていた
SQL Server Agent のジョブは、ステップの種類や設定によって“どの Windows アカウントで OS にアクセスするか”が変わります。ここがズレると、権限設計もズレます。
| ジョブステップの種類（例） | OS 上の実行主体（代表パターン） | 権限がズレる原因 |
|---|---|---|
| Operating system (CmdExec) | SQL Agent サービスアカウント、または設定した Proxy | 「ジョブ所有者＝実行ユーザー」と誤解する |
| PowerShell | SQL Agent サービスアカウント、または設定した Proxy | スクリプト内のアクセス先が UNC/ローカルで混在 |
| T-SQL（DBエンジン処理） | SQL Server サービスアカウント（ファイル操作が絡む処理の場合） | バックアップ/インポート等で OS 権限の主体を見落とす |
もし実際の実行主体が mydomain\jobuser ではなく、SQL Agent/SQL Server のサービスアカウント（例：mydomain\sqlsvc）だった場合、権限を追加すべき対象も変わります。逆に、あなたが NTFS に jobuser を追加したことで偶然「本当の実行主体が所属しているグループも許可された」など、間接的に解決することもあります。
このズレを潰すのが、トラブルシュートを最短にします。
切り分けの基本：どこで拒否されたかを “証拠付き” で確認する
「共有か NTFS のどちらが悪い？」を勘でやると沼に入りがちです。以下の順で、事実を積み上げるのが効率的です。
共有名・共有先パス・共有権限をサーバー側で確定する
まず「その UNC が、どの共有名で、どのローカルパスを指しているか」を確定します。GUI では取り違えが起きやすいので、コマンド/PowerShell が確実です。
共有一覧（共有名とパス）
net sharePowerShell（共有情報）
Get-SmbShare
Get-SmbShare -Name "mydatafolder" | Format-List *共有権限（Share Access）
Get-SmbShareAccess -Name "mydatafolder"ここで「Administrators のみ」なのか、「Authenticated Users に Change が付いている」のか、事実が確定します。
NTFS 権限を “文字列で” 見える化する
エクスプローラーの画面だけだと、継承や拒否（Deny）の存在が見落とされることがあります。NTFS は icacls で文字として押さえるのが堅いです。
icacls "D:\mydatafolder"サブフォルダーまで確認したい場合（継承の破断があるケース）
icacls "D:\mydatafolder" /Tよくある「追加したのにまだ拒否される」原因は、次のようなパターンです。
- 上位フォルダーで継承が切れていて、期待した権限が降りていない
- どこかに Deny（拒否） が入っていて Allow より優先されている
- 「読み取りはできるが作成（Create）ができない」など、権限粒度が不足している
“Effective Access（有効なアクセス権）” で最終結果を確認する
Windows Server 2019 では、フォルダーのプロパティから有効なアクセス権を確認できます。
- 対象フォルダーを右クリック →［プロパティ］→［セキュリティ］→［詳細設定］
- ［有効なアクセス権］（Effective Access）で
mydomain\jobuserを指定
ここで「書き込みが許可されているか」が視覚的に確認できます。共有権限まで含めた完全な“ネットワーク越しの最終結果”を一発で出すのは難しい場面もありますが、少なくとも NTFS 側の詰まりはこの時点で白黒つきます。
実際に“jobuser と同条件”で UNC にアクセスしてテストする
最終的には「そのユーザーのトークンで、ネットワーク越しに書けるか」を試すのが決定打です。サーバー上で実施できるなら、次のようにすると再現性が高いです。
runas /user:mydomain\jobuser cmd開いたコマンドプロンプトで、UNC へテスト書き込み。
dir \\myserver\mydatafolder\
echo test > \\myserver\mydatafolder\_perm_test.txtここで拒否されるなら、共有権限または NTFS のどちらか（または両方）がまだ不足しています。逆にここで成功するなら、SQL ジョブ側の“実行主体の取り違え”や“パスの取り違え”が疑わしくなります。
なぜ「共有権限が Administrators のみ」に見えたのか？現場で多い解釈ズレ
質問の核心はここです。「共有権限が Administrators のみなら、通常は jobuser で UNC 書き込みできないはず」。それでも NTFS だけで直ったなら、次のどれかの可能性が濃厚です。
共有権限ではなく NTFS（セキュリティタブ）を見ていた
これは最頻出です。Windows の UI では「権限」という言葉が多く登場しますが、セキュリティタブは基本的に NTFS を示します。
共有権限を確認する場所（例）
- フォルダー右クリック →［プロパティ］→［共有］→［詳細な共有］→［アクセス許可］
- または PowerShell の
Get-SmbShareAccess
同じフォルダーが別の共有名で公開されていた
同一フォルダーを複数共有することは可能です。たとえば：
\\myserver\mydatafolder（業務用：共有権限は広い）\\myserver\mydatafolder_admin（管理用：Administrators のみ）
この場合、「管理用の共有の権限」を見ていた可能性があります。net share の結果に共有名が複数出ていないか、共有パスがどれも同じになっていないかを確認してください。
SQL ジョブが実は UNC ではなくローカルに書いていた
UNC に見える“入力パラメータ”でも、スクリプトが変換していたり、アプリが一時ファイルをローカルに作ってから移動していたりします。NTFS を足したら直るのは、このパターンと整合します。
そもそも jobuser ではなく、管理権限を持つアカウントでアクセスしていた
例えば、SQL Agent サービスアカウントがローカル管理者で、共有権限が Administrators のみだった場合、ジョブは管理者権限で通ってしまいます。あなたが「実行アカウントは jobuser」と思っていても、ステップ設定がそうなっていないことがあります。
特に次の点は確認価値が高いです。
- SQL Server Agent サービスのログオンアカウント
- ジョブステップごとに Proxy を設定しているか
- ジョブ所有者（Owner）と実行主体を混同していないか
実務で役立つ：症状から当たりを付ける早見表
| 症状 | 可能性が高い原因 | 最短の確認 | 対処の方向性 |
|---|---|---|---|
| ローカルでは書けるが UNC だと Access Denied | 共有権限が不足 / SMB 経由の制限 | Get-SmbShareAccess と runas で UNC 書き込みテスト | 共有権限を見直す（グループ経由含む） |
| UNC でも閲覧できるが作成だけ失敗 | NTFS の「作成/書き込み」不足、継承断、Deny | icacls / Effective Access | NTFS の Modify 相当を付与（できればグループ） |
| 管理者で実行すると成功、jobuser だと失敗 | 共有/NTFS のどちらかが Administrators にしか許可されていない | runas で同条件テスト | 最小権限で jobuser（または役割グループ）を許可 |
| NTFS を足したら突然直った | 共有は元々通っていた / UNC ではなくローカルだった / 実行主体が別 | 共有権限の実態とジョブの実行主体を確認 | 構成の事実を確定し、設計を整理 |
トラブルを減らす権限設計の“現場向けベストプラクティス”
「今回たまたま直った」状態を放置すると、次のメンテナンスや人の入れ替えで再発しやすくなります。共有フォルダー運用は、次の形に寄せると安定します。
ユーザー直付けを避け、役割グループで管理する
例えば、SQL ジョブで書く用途なら、ユーザー個人ではなく “用途グループ” を作ります。
- 例：
GG_SQLJob_FileWrite（グローバルグループ） - メンバー：
mydomain\jobuser（必要なら複数） - 共有権限：
GG_SQLJob_FileWriteに変更（Change） - NTFS 権限：対象フォルダーに Modify（変更）相当
こうすると、担当者交代や複数ジョブ対応が圧倒的に楽になります。
共有権限は“広め + 最小限”、実制御は NTFS で統一する
共有権限まで厳密に作り込むと、トラブルシュートが難しくなりがちです。運用の定番は次のいずれかです。
| 運用方針 | 共有権限 | NTFS | 向いている現場 |
|---|---|---|---|
| NTFS 主体（推奨寄り） | Authenticated Users：変更（または読み取り） | 部署/用途グループで厳密に制御 | 共有が多い、権限変更が頻繁、運用メンバーが複数 |
| 多層で厳密 | 共有もグループで細かく制御 | NTFS も同様に制御 | 監査要件が強い、変更頻度が低い、設計が固い |
どちらを選ぶにせよ、「共有と NTFS の両方を触らないと直せない状態」より、「普段触るのは NTFS（またはグループ）だけ」という形のほうが、事故が減ります。
“Deny（拒否）” は最後の手段にする
権限トラブルで最も時間を溶かすのが Deny です。Allow より優先されるため、グループが複雑になると原因追跡が難しくなります。基本は Allow の組み合わせで解決し、どうしても必要なときだけ Deny を使うのが安全です。
よくある質問：結局、今回のケースはどう説明できる？
状況から最も可能性が高い説明は、次のいずれか（または複合）です。
- 共有権限は実は jobuser（または所属グループ）に許可されていて、NTFS だけが不足していた。 そのため NTFS を足した瞬間に通った。
- SQL ジョブが UNC ではなくローカルパスへ書いていた。 共有権限は評価されず、NTFS のみが勝負だった。
- 実行主体が jobuser ではなく、SQL Agent/SQL Server のサービスアカウントだった。 共有権限の “Administrators のみ” と整合するケースもある。
- 確認していた共有が違った（同一フォルダーの別共有、DFS、別 share 名）。
これらは「共有権限も NTFS も必要」という原則を否定しません。“必要” というルールと、“今回詰まっていたのはどこか” は別問題、というのがポイントです。
再発防止のチェックリスト（そのまま使える）
- アクセス対象の UNC（共有名）と、実体パス（ローカルパス）を
net share/Get-SmbShareで一致させた - 共有権限を
Get-SmbShareAccessで確認し、job の実行主体（または用途グループ）が許可されている - NTFS を
icaclsで確認し、Deny や継承断で想定外がない - Effective Access で “最終的に書ける” を確認した
- ユーザー直付けではなく、用途グループ（例：
GG_SQLJob_FileWrite）で付与した - ジョブステップごとに「どの Windows アカウントで動くか」をドキュメント化した
このチェックが揃えば、「共有権限を触っていないのに直った」ように見える状況でも、なぜそうなったかを説明でき、次に同じ手戻りが起きにくくなります。
コメント