這可能是模擬和發生不同身份驗證方法不匹配的組合。
有很多件;我會試着一個接一個地過去。
冒充是一種技術，用於「臨時」切換線程正在運行的用戶帳戶。從本質上講，該線程短暫地獲得相同的權利和訪問權限 - 不多也不少於作爲被模擬的帳戶。只要線程完成創建網頁，它就會「恢復」回原始帳戶，併爲下一次呼叫做好準備。此技術用於訪問只有登錄到您的網站的用戶纔有權訪問的資源。堅持一分鐘的概念。
現在，默認情況下，ASP.NET在本地帳戶下運行一個名爲ASPNET的網站。同樣，默認情況下，只有ASPNET帳戶和Administrators組的成員可以寫入該文件夾。您的臨時文件夾在該帳戶的權限範圍內。這是謎題的第二部分。
冒充不會自行發生。它需要在你的web.config中有意打開。
<identity impersonate="true" />
如果設置丟失或設置爲false，那麼您的代碼將在上述ASPNET帳戶下執行純粹且簡單的操作。鑑於你的錯誤信息，我確信你有模擬=真實。沒有什麼不妥！假冒的優點和缺點超出了這個討論範圍。
還有一個問題：當你使用模擬，哪個帳號被冒充？
除非您在web.config（full syntax of the identity element here）中指定帳戶，否則模擬的帳戶是IIS交給ASP.NET的帳戶。這取決於用戶如何驗證（或不驗證）到網站中。這是你的第三件也是最後一件。
IUSR_ComputerName帳戶是由IIS創建的低權限帳戶。默認情況下，如果用戶無法通過驗證，則此帳戶是網絡電話運行的帳戶。也就是說，用戶以「匿名」的身份進入。
總之，這是發生了什麼事給你：
您的用戶試圖訪問該網站，和IIS無法驗證某些原因的人。由於匿名訪問爲ON（或者您不會看到IUSRComputerName訪問臨時文件夾），因此IIS允許用戶以任何方式訪問，但是以普通用戶身份訪問。您的ASP.NET代碼將運行並模擬此通用IUSR___計算機名「guest」帳戶;只有現在，代碼才能訪問ASPNET帳戶有權訪問的內容，包括其自己的臨時文件夾。
授予IUSR_ComputerName WRITE對文件夾的訪問權使您的症狀消失。
但這只是症狀。您需要查看爲什麼這個人會以「匿名/訪客」的身份來訪問？
有兩種可能的情況：
一）你打算使用IIS進行身份驗證，但IIS身份驗證設置爲你的一些服務器是錯誤的。
在這種情況下，您需要禁用這些服務器上的匿名訪問權限，以便執行通常的身份驗證機制。請注意，您可能仍然需要授予您的用戶對該臨時文件夾的訪問權限，或者使用其他文件夾，而不是您的用戶已有權訪問的文件夾。
我已經多次與這個場景合作過了，坦率地說，它讓你減少了放置Temp文件夾的麻煩;在服務器中創建一個專用文件夾，設置適當的權限，並在web.config中設置其位置。
b）你並不想反正認證的人，或者你想使用ASP.NET窗體身份驗證（使用IIS的匿名訪問繞過檢查在IIS和ASP.NET可以直接處理認證）
這種情況有點複雜。
您應該轉到IIS並禁用「匿名訪問」以外的所有形式的身份驗證。請注意，您不能在開發人員的方框中執行此操作，因爲調試器需要啓用集成身份驗證。所以你的調試盒會比真實的服務器表現得有點不同;請注意這一點。
然後，您需要決定是關閉模擬還是反過來指定要在web.config中模擬的帳戶。如果您的Web服務器不需要外部資源（如數據庫），請首先執行操作。如果您的網站確實需要在可訪問數據庫（或其他外部資源）的帳戶下運行，請執行後者。
您有另外兩種替代方法來指定要模擬的帳戶。一，你可以去IIS並將「匿名」帳戶改爲可以訪問資源的帳戶，而不是IIS管理的帳戶。第二種選擇是隱藏在註冊表中加密的帳戶和密碼。這一步有點複雜，也超出了本次討論的範圍。
祝你好運！