更新：我最初發布的「in」目錄位於C：上。它實際上在E：上。 D：和E：是RAID上的卷。我不會期望有所作爲，但如果我知道發生了什麼，我就不必提問了。由HTTP處理程序創建的目錄權限，由用戶訪問
我遇到一個必須由Web服務和本地用戶控制的目錄的ACL權限問題。這是我的第一個涉及目錄安全和ACL的項目，所以我擔心我正在考慮全部錯誤。我願意提供一個解決方案的答案，以及那些能夠提出對我的安全模型進行全面改革的答案。
我正在從Windows Server 2012 R2 Web服務工作，該服務從多個用戶（節點）捕獲數據，然後對其進行處理。我有每個節點目錄（例如E：\ in \ node1，E：\ in \ node2等）來保存傳入數據，然後我使用一個C＃控制檯應用程序作爲非管理本地用戶（LocalUser ）將文件移動到更大的卷，並使用更深層的目錄結構來反映控制檯應用程序所做的分類。
最初，我將創建每個節點的目錄作爲LocalUser，但爲了可管理性，我做了一個Web服務（POST Handler）來創建節點目錄，因爲每個節點都被調配和配置。
我現在有一個文件系統，其中一些目錄由LocalUser創建，一些由DefaultAppPool通過Web服務創建。兩種類型的目錄都按預期接收文件。當我以LocalUser身份運行我的控制檯應用程序時，對於LocalUser創建的目錄，一切正常，但是當我嘗試將File.Move（）從Web創建的Node目錄設置爲Web創建的Classification目錄時，我得到UnauthorizedAccessException。當我查看ACL時，發現問題在於Creator（和完全控制帳戶）與運行控制檯應用程序的帳戶不同。另外，ACL頁面說E：\ in \ node2從E：，而不是E：\ in繼承。
Web供應的關鍵在於自動化系統，所以我不希望觸及所有新目錄以添加LocalUser（或包含LocalUser的組）。我還希望系統在其他經過身份驗證的用戶嘗試運行控制檯應用程序（例如，從未在任何地方創建任何目錄的LocalUser2）時工作。
看來，我必須解決這個問題的兩個機會是1）Web服務創建目錄時，或2）LocalUser運行腳本時。不幸的是，我擔心這兩個賬戶（DefaultAppPool，LocalUser）都沒有權限授予（情況1））或者獲取（情況2））完全控制有問題的目錄。最終，我計劃從Web服務運行控制檯應用程序，並且這將使所有內容運行爲DefaultAppPool，但是在開發過程中以及作爲手動維護操作，我希望能夠在控制檯上運行控制檯應用程序作爲LocalUser或LocalUser2的需求。我認爲在運行控制檯應用程序時可以創建一些模擬DefaultAppPool的「填充程序」，但據我所知，做這種模擬的唯一方法是讓Web服務執行此操作。
總之，我怎麼能有一個系統，其中Web服務創建的目錄，然後可以由用戶在一個特定的組中控制？
謝謝你，你已經重申了這個問題。 – verbamour
我將編輯該問題以添加更多細節。當我說目錄根目錄是c：\ in時，我過度簡化了，它實際上是在e：上。當我查看ACL時，它們從e：\繼承，而不是e：\ in。那是意想不到的。一旦我確定我正在查看最新的代碼，我會發布製作目錄的代碼片段。我還將對父目錄的當前ACL進行另一次檢查，然後再次嘗試查看是否可以使用適當的繼承創建一個目錄。 – verbamour
您已經寫過卷D：和E：位於RAID上。它們是否在外部存儲系統上，可能不是Windows系統？我問，因爲外部系統可能會負責設置和繼承實際的訪問權限。 Windows服務器會以預期的方式感知權限的模擬。如果是這種情況，可能需要仔細研究存儲系統如何處理訪問權限。 – roadkill