更新:私は最初、「in」ディレクトリが C: にあると投稿しました。実際には E: にあります。D: と E: は RAID 上のボリュームです。それが違いを生むとは思いませんが、何が起こっているのかを知っていれば、質問する必要はなかったでしょう.
Web サービスとローカル ユーザーの両方で制御する必要があるディレクトリの ACL 権限に問題があります。これは、ディレクトリ セキュリティと ACL を含む私の最初のプロジェクトであるため、これについてすべて間違って考えているのではないかと心配しています。ポイントフィックスを提供する回答と、セキュリティモデルのオーバーホールを提案する回答を受け入れます。
私は、多数のユーザー (ノード) からデータを取得して処理する Windows Server 2012 R2 Web サービスに取り組んでいます。ノードごとのディレクトリ (例: E:\in\node1、E:\in\node2 など) に着信データを保持してから、非管理ローカル ユーザー (LocalUser) として実行する C# コンソール アプリを使用します。 ) コンソール アプリによって行われた分類を反映する、より深いディレクトリ構造を持つより大きなボリュームにファイルを移動します。
最初は、各ノードのディレクトリを LocalUser として作成しますが、管理を容易にするために、各ノードがプロビジョニングおよび構成されるたびにノード ディレクトリを作成する Web サービス (POST ハンドラー) を作成しました。
これで、LocalUser によって作成されたディレクトリと、Web サービスを介して DefaultAppPool によって作成されたディレクトリを持つファイル システムができました。どちらのタイプのディレクトリも、期待どおりにファイルを受け取ります。コンソール アプリを LocalUser として実行すると、LocalUser で作成されたディレクトリに対してはすべて正常に機能しますが、Web で作成された Node ディレクトリから Web で作成された Classification ディレクトリに File.Move() を実行しようとすると UnauthorizedAccessException が発生します。ACL を見ると、Creator (およびフル コントロールを持つアカウント) がコンソール アプリを実行しているアカウントとは異なることが問題であることがわかります。また、ACL ページには、 E:\in\node2 が E:\in ではなく E: から継承されたことが示されています。
Web プロビジョニングの要点はシステムを自動化することだったので、LocalUser (または LocalUser を含むグループ) を追加するためにすべての新しいディレクトリに手を加える必要はありません。また、他の認証されたユーザーがコンソール アプリを実行しようとしたときにシステムが機能することも望んでいます (たとえば、どこにもディレクトリを作成したことがない LocalUser2 など)。
これを修正する必要がある 2 つの機会は、1) Web サービスがディレクトリを作成するとき、または 2) LocalUser がスクリプトを実行するときのようです。残念ながら、どちらのアカウント (DefaultAppPool、LocalUser) にも、問題のディレクトリのフル コントロールを付与 (ケース 1)) または押収 (ケース 2)) する権限がないことが懸念されます。
最終的には、Web サービスからコンソール アプリを実行する予定です。これにより、すべてが DefaultAppPool として実行されますが、開発中および手動のメンテナンス操作として、必要に応じてコンソール アプリを LocalUser またはとして実行できるようにしたいと考えています。 LocalUser2。コンソール アプリの実行中に DefaultAppPool を偽装するある種の「シム」を作成できるのではないかと考えていましたが、私が知る限り、そのような偽装を行う唯一の方法は、Web サービスに実行させることです。
要約すると、Web サービスがディレクトリを作成し、特定のグループのユーザーがそのディレクトリを制御できるようにするにはどうすればよいでしょうか?