Question

Je sais que cette question a été posée plusieurs fois ici, mais je ne trouve pas de solution à mon problème. J'essaye d'enregistrer l'image dans le dossier en .net c # mais j'obtiens cette exception:

Access to the path 'C:\inetpub\wwwroot\mysite\images\savehere' is denied.The error occured at mscorlib because    at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode)

J'ai donné le contrôle total de ce dossier (savehere) à network service et iis_iusrs, j'ai même donné le contrôle total à everyone mais j'ai toujours cette exception. J'ai essayé de donner accès via l'explorateur et via le gestionnaire IIS, toujours pas de chance

Je le fais sur Windows Server 2008 R2 et IIS 7.5, de qui ai-je besoin pour donner accès?

Merci

Était-ce utile?

La solution

Vous devez trouver dans le pool d'applications du site Web quelle est l'identité sous laquelle il s'exécute (par défaut, il s'agit de Application Pool Identity) et lui accorder les autorisations appropriées.

Autres conseils

L'accès au chemin 'C: \ inetpub \ wwwroot \ mysite \ images \ savehere' est refusé

Lisez attentivement le message.Vous essayez d'enregistrer dans un fichier portant le même nom que le répertoire.Cela ne peut pas fonctionner, vous ne pouvez pas écraser un répertoire rempli de fichiers avec un seul nouveau fichier.Cela entraînerait une perte de données non diagnostiquée. «L'accès au chemin est refusé» est le système de fichiers qui riposte pour empêcher que cela ne se produise.

Le message d'exception n'est pas idéal, mais il vient directement du système d'exploitation et ils sont gravés dans le marbre.Le framework ajoute souvent des contrôles supplémentaires pour générer de meilleurs messages, mais il s'agit d'un test coûteux sur un réseau.Perf est également une fonctionnalité.

Vous devez utiliser un nom comme 'C: \ inetpub \ wwwroot \ mysite \ images \ savehere \ mumble.jpg'.Considérez Path.Combine () pour générer de manière fiable le nom du chemin.

J'avais le même problème en essayant de créer un fichier sur le serveur (en fait un fichier qui est une copie d'un modèle).

Voici le message d'erreur complet:

{ERROR} 08/07/2012 22:15:58 - System.UnauthorizedAccessException: Access to the path 'C:\inetpub\wwwroot\SAvE\Templates\Cover.pdf' is denied.

J'ai ajouté un nouveau dossier appelé Templates dans le dossier de l'application IIS.Une chose très importante dans mon cas est que je devais donner l'autorisation d'écriture (Gravar) à l'utilisateur IUSR sur ce dossier.Vous devrez peut-être également donner à Network Service et ASP.NET v$.# la même autorisation d'écriture.

entrez la description de l

Après cela, tout fonctionne comme prévu.

J'ai eu exactement le même problème.

La solution était que le fichier auquel j'essayais d'accéder était en lecture seule , car il était copié à partir d'un fichier modèle en lecture seule.

J'ai eu ce problème lorsque j'essaie d'enregistrer le fichier sans définir le nom du fichier.

Ancien code

File.WriteAllBytes(@"E:\Folder", Convert.FromBase64String(Base64String));

Code de travail

File.WriteAllBytes(@"E:\Folder\"+ fileName, Convert.FromBase64String(Base64String));

Mon problème était que je devais demander un accès en lecture uniquement:

FileStream fs = new FileStream(name, FileMode.Open, FileAccess.Read);

veuillez ajouter l'autorisation de contrôle total IIS_IUSERS à votre dossier. vous trouvez cette option dans l'onglet de sécurité dans les propriétés du dossier. trouver cette option et l

Quelle est l'identité de votre pool d'applications pour l'application Web exécutée sous, pour résoudre le problème, essayez de créer un nouveau pool d'applications avec, par exemple, le service réseau comme identité et faites en sorte que votre application Web utilise ce nouveau pool d'applications que vous avez créé et voyez si l'erreur persiste.

Le conseil suivant n'est pas une réponse à la question initiale de ce fil, mais pourrait aider d'autres utilisateurs qui se retrouvent sur cette page Web, après avoir commis la même erreur stupide que je viens de faire ...

J'essayais d'obtenir un contrôle ASP.Net FileUpload pour télécharger son fichier vers une adresse réseau contenant un " partage caché ", à savoir:

<₹\MyNetworkServer\c$\SomeDirectoryOrOther

Je n'ai pas compris. Si j'exécutais la page Web en mode débogage dans Visual Studio, cela fonctionnerait bien. Mais lorsque le projet a été déployé et s’exécutait via un utilisateur du pool d’applications, il a refusé de trouver ce répertoire réseau.

J'avais vérifié avec quel utilisateur mon site IIS fonctionnait, j'ai donné à cet utilisateur les autorisations complètes sur ce répertoire sur le serveur " MyNetworkServer ", etc., mais rien n'a fonctionné.

La raison (bien sûr!) est que seuls les administrateurs peuvent "voir" ces partages de lecteurs cachés.

Ma solution était simplement de créer un partage "normal" vers

< \MyNetworkServer\SomeDirectoryOrOther

et cela a éliminé l'erreur "L'accès au chemin ... est refusé". FileUpload a réussi à exécuter la commande

fileUpload.SaveAs(networkFilename);

J'espère que cela aidera d'autres utilisateurs qui font la même erreur que moi!

Notez également que si vous téléchargez des fichiers volumineux (plus de 4 Mo), IIS7 vous oblige à modifier le fichier web.config à deux emplacements. Cliquez sur ce lien pour lire ce que vous devez faire: Téléchargement de fichiers volumineux dans ASP.Net

J'ai résolu avec ce paramètre:

IIS> Pools d'applications> [votre site]> Paramètres avancés ...> Identité> Compte intégré> LocalSystem

Mon problème était quelque chose comme ça:

FileStream ms = new FileStream(path, FileMode.Open, FileAccess.ReadWrite);

mais au lieu d'utiliser le chemin, je devrais utiliser File.FullName ... Je ne sais pas si ça va aider quelqu'un d'autre, juste en passant ma propre expérience avec cette erreur!

  1. Modifiez le paramètre de compte intégré en compte personnalisé et saisissez le nom d'utilisateur et le mot de passe de l'autre serveur.

  2. Conservez le paramètre intégré (au lieu du mode classique).

Peut-être que cela vous aidera.

string tempDirectoryPath = @"C:\Users\HOPE\Desktop\Test Folder";
string zipFilePath = @"C:\Users\HOPE\Desktop\7za920.zip";
Directory.CreateDirectory(tempDirectoryPath);
ZipFile.ExtractToDirectory(zipFilePath, tempDirectoryPath);

Faites de Directory savehere un répertoire virtuel et donnez l'autorisation de lecture / écriture depuis le panneau de configuration

Il y avait un répertoire du même nom que le fichier que j'essayais d'écrire, donc les gens peuvent aussi le rechercher.

J'ai rencontré ce problème lors du développement sur mon poste de travail local.

Après plusieurs invocations infructueuses de iisreset, j'ai remédié à cette situation en redémarrant ma machine.

Rétrospectivement, un descripteur de fichier ouvert peut avoir causé des problèmes.

Dans mon cas, j'ai dû ajouter une règle d'autorisation .NET pour le site Web dans IIS.

J'ai ajouté une règle pour autoriser les utilisateurs anonymes.

. NET Authorization Rules

J'ai eu le même problème mais je l'ai résolu en enregistrant le fichier dans un emplacement différent, puis en copiant le fichier et en le collant à l'emplacement où je voulais qu'il soit.J'ai utilisé l'option pour remplacer le fichier existant et cela a fait l'affaire pour moi.Je sais que ce n'est pas le moyen le plus efficace, mais cela fonctionne et prend moins de 15 secondes.

J'ai eu beaucoup de problèmes avec cela, spécifiquement liés à mon code s'exécutant localement, mais lorsque je devais l'exécuter sur IIS, cela provoquait une erreur.J'ai trouvé que l'ajout d'une vérification à mon code et le fait de laisser l'application créer le dossier lors de la première exécution résolvaient le problème sans avoir à modifier les autorisations des dossiers.

quelque chose comme ça avant d'appeler votre méthode qui utilise le dossier

bool exists = System.IO.Directory.Exists("mypath");

        if (!exists)
            System.IO.Directory.CreateDirectory("mypath");

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top