IIS ApplicationPoolIdentity n'a pas le droit d'écriture sur 'Fichiers temporaires ASP.NET'
Je tente de lancer un site Web à partir d'un "AppPool" appelé "SomeAppPool" qui utilise "ApplicationPoolIdentity" et quand je reçois le message d'erreur suivant lorsque je lance le site Web:
L'identité actuelle (IIS_APPPOOL\SomeAppPool) n'a pas d'accès en écriture à 'c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\Fichiers ASP.NET temporaires'
Je lance le site Web avec "Utiliser le serveur Web local IIS" dans Visual Studio 2012 (sans débogueur attaché) sous Windows 8.
La première chose que j'ai remarquée est que le dossier 'Fichiers temporaires ASP.NET' n'existe même pas Il n'existe donc aucun élément pour lequel définir des autorisations de sécurité.
Le deuxième problème est, même s'il y avait un dossier, quelles autorisations devrais-je définir? Je suppose que je ne devrais pas avoir à définir d'autorisations pour chaque utilisateur créé via "ApplicationPoolIdentity". Droite?
Les solutions actuelles que j'ai vues suggèrent simplement de définir l'utilisateur sur "Service réseau" Mais cela semble rompre l'isolement du site Web pour lequel "ApplicationPoolIdentity" a été introduit.
Cette réponse du forum ASP.NET , non reconnue dans son fil, était la solution pour moi. Cela a également un faible impact: il n'essaie pas de réenregistrer IIS ou de donner des privilèges dangereux à l'utilisateur. Pour résumer la réponse:
- Ouvrez une fenêtre de commande en tant qu'administrateur (Démarrer/Programmes/Accessoires, cliquez ensuite sur une invite de commande avec le bouton droit de la souris, puis choisissez "Exécuter en tant qu'administrateur").
Entrez la commande suivante:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Aspnet_regiis.exe -ga domain\user
Remplacez domain\user par votre domaine et votre utilisateur dans l'exemple ci-dessus. C'est tout ce qu'il a fallu.
La documentation Microsoft pour Aspnet_regiis.exe est ici . Notez que la documentation du commutateur -ga fait référence à un bogue dans les versions 3.5 et antérieures, dans lequel cela ne fonctionnerait pas avec les comptes locaux. Si je le lis correctement, les comptes de domaine sont pris en charge pour toutes les versions et les comptes locaux sont pris en charge à partir de Framework 4.0.
Mise à jour 6 juin 2017: Sous Windows 8 et supérieur, considérons plutôt la commande dism. Cela est couvert dans cette SO réponse . Merci à @codebrain pour cette suggestion.
Mise à jour 7 juillet 2015: @Vertigo a gentiment fait remarquer que cette réponse fonctionnait également pour le compte NETWORK SERVICE dans .NET 2.0 sous 2008R2/2012; mon avertissement concernant les comptes locaux antérieurs à 4.0 peut donc être erroné.
Si quelqu'un d'autre trouve que cela fonctionne pour un compte local sous .NET 3.5 ou version antérieure, n'hésitez pas à modifier ma réponse ou à la noter dans les commentaires. ce serait une grande aide pour les autres personnes susceptibles de rencontrer le même problème.
Veuillez vérifier votre espace disque et vous assurer qu'il y en a assez.
Je viens de rencontrer ce problème sur l'un de nos serveurs de production et cela était lié au manque d'espace disque.
J'ai résolu l'erreur en ajoutant l'utilisateur que le pool d'applications utilise dans le groupe IIS_IUSRS.
J'ai rencontré le même problème. J'ai vérifié le chemin c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\ à la recherche de Temporary ASP.NET Files, mais il n'y avait aucun dossier portant ce nom. donc j'ai créé un nouveau dossier manuellement et l'ai nommé Temporary ASP.NET Files et le problème a été résolu.
Donc, assurez-vous que le chemin mentionné existe.
Étant dans le C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319, essayez d’exécuter la commande aspnet_regiis.exe.
En règle générale, les autorisations doivent être configurées. Si des programmes Ajout/Suppression Windows se produisent ou si de nouvelles versions .NET sont installées, ces opérations sont réinitialisées. Exécuter le aspnet_regiis.exe devrait y aider.
Assurez-vous également que vous exécutez Visual Studio en tant qu'administrateur.
Je viens de rencontrer ceci et ce que j'ai fait était de créer un nouveau compte, disons que c'est "Webby".
Dans ISS, accédez aux paramètres avancés de votre page et remplacez "Informations d'identification du chemin physique" par le compte Webby. Le champ Chemin ci-dessus qui contient le répertoire de la page Web; ouvrez ce dossier dans l'explorateur et ajoutez Webby avec les autorisations de modification. Sous "Suivi de demande ayant échoué", vous trouverez un répertoire de journaux. ajoutez également modifier et définissez "Enabled" sur true (vous pouvez le désactiver plus tard, mais assurez-vous que cela fonctionnera) . À ce stade, vous pouvez essayer votre site et vous devez absolument obtenir le message d'erreur, car de l'utilisateur que vous utilisez.
L’identité actuelle (YOUR\Webby) n’a pas d’accès en écriture aux fichiers 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET'.
Maintenant, pour résoudre votre problème, vous devrez vous rendre dans le répertoire "Fichiers ASP.NET" de C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary et y ajouter Webby également, à nouveau, le travail de modification fonctionne.
La solution consistant à utiliser un compte spécial uniquement pour les sites Web est une bonne idée. C'est un compte réel (pas virtuel comme ApplicationPool) et Windows ne s'embrouille pas (... aussi facilement).
J'espère que cela t'aides.
je l'ai résolu en libérant de l'espace disque
Dans IIS7, j'ai cliqué avec le bouton droit sur le répertoire virtuel, supprimé l'application et l'a ajouté à nouveau. Cela a réglé le problème pour moi.