ASP.NET MVC NESTED виртуална директория за файлове със съдържание

Опитвам се да картографирам виртуална директория в моя уебсайт ASP.NET MVC 3. Виртуалната директория съдържа само файлове с изображения, а физическата директория се намира на друг сървър. Когато се опитам да получа достъп до изображение от тази директория чрез уеб браузър, получавам грешка HTTP 500:

Parser Error Message: An error occurred loading a configuration file: Failed to start monitoring changes to '<virtual directory path>' because access is denied.

[РЕДАКТИРАНЕ]: След рестартиране на IIS виждам, че е добавено „достъпът е отказан“ в края на съобщението за грешка. Директорията обаче има разрешение „Всички“ с достъп за четене и все още не работи. Виждал съм публикации, които подробно описват същата грешка, но решението за настройка на разрешения не работи за мен.

Защо търси конфигурационен файл? Актуализирах своя Global.asax, за да игнорирам въпросния маршрут и от IIS 6 мога да преглеждам файловете, разположени във виртуалната директория, без проблем. Проверих, че виртуалната директория НЕ е настроена като приложение. Освен това разрешенията за директорията имат достъп за четене за всеки. какво правя грешно

[РЕДАКТИРАНЕ #2]: Виртуалната директория, към която се сочи, е споделена мрежова папка... Това има ли някаква разлика?

[РЕДАКТИРАНЕ #3]: Йерархията на IIS 6 за това, което се опитвам да направя, е следната: Уебсайт по подразбиране -> Нашият сайт (MVC уебсайт, който САМИЯТ САМ е виртуална директория) -> Изображения (виртуална директория, с която се боря). Определено има проблем с факта, че това е вложена виртуална директория; ако създам директорията като директно дъщерно на Default Website вместо Default Website -> OurSite, тя работи добре.

Благодаря,

Анди


asp.net-mvc iis virtual-directory
person Andy    schedule 30.05.2012    source източник

Отговори (2)


arrow_upward
1
arrow_downward

Уверете се, че самоличността, изпълняваща набора от приложения, също има разрешения за изпълнение и списък на тази виртуална папка, тъй като се опитва да я наблюдава за промени за кеширане.

http://support.microsoft.com/kb/316721/

[РЕДАКТИРАНЕ] Тази връзка показва, че може да е вторият случай, в който няма разрешения за подпапка в споделената директория.

http://support.microsoft.com/kb/317955

Акаунтът ASPNET има ли достъп докрай това дърво?

person Turnkey    schedule 30.05.2012
comment
Благодаря за отговора. За съжаление това не работи за мен. Наборът от приложения, под който работи сайтът, използва идентичност: МРЕЖОВА УСЛУГА и аз добавих разрешения за този конкретен потребител както на ниво уебсайт, така и на ниво виртуална директория. Връзката, която изпратихте, казва, че ако всеки потребител има достъп, тогава не трябва да добавяте потребителя на набора от приложения, но сега и двамата потребители имат достъп и все още не работи. - person Andy; 30.05.2012
comment
Видях друга статия от KB, която предполага, че може да е по-дълбоко в пътя на директорията за това споделено устройство. Може да видите какви самоличности имат достъп, които споделят OK в подпапките. - person Turnkey; 30.05.2012
comment
Уверих се, че цялата йерархия на споделената папка има разрешения, дадени на NETWORK SERVICE, IUSR_machinename и ASPNET, и тя все още не работи. - person Andy; 31.05.2012
comment
ОК - така че виртуалната директория, която създадох, съществува като дете на уебсайта, който САМИЯТ е виртуална директория под Уебсайт по подразбиране. Ако създам виртуалната директория директно под Уебсайт по подразбиране, тогава тя работи добре. Защо не можете да правите вложени виртуални директории? - person Andy; 31.05.2012
comment
Това е много добър въпрос, особено след като VD се съдържа в собствена уеб папка. Чудя се дали разрешава пътя правилно. Съдържанието на пътя на виртуалната директория в съобщението за грешка по-горе беше скрито, показваше ли правилния разширен път в действителното съобщение за грешка? - person Turnkey; 31.05.2012
comment
Да, отчете пътя до мрежовия дял: \\server\e$\directory. - person Andy; 02.06.2012

arrow_upward
0
arrow_downward

Четейки отговора на Turnkey и вашите коментари, просто исках да отбележа, че ако вашият AppPool използва NETWORK SERVICE самоличност, тогава вашият отдалечен сървър трябва да добави акаунта за машина/компютър на уеб сървъра към споделената папка и NTFS разрешения < силно>НЕ NETWORK SERVICE акаунта.
Ако добавите NETWORK SERVICE към споделената папка и NTFS разрешения, вие просто добавяте NETWORK SERVICE акаунта на локалната машина, а не уеб NETWORK SERVICE акаунт на сървър. Надявам се, че имам смисъл.
Всеки път, когато използвате NETWORK SERVICE акаунта на компютъра, за да се свържете дистанционно, вие на практика използвате машинния акаунт на компютъра, така че това е, което трябва да добавите.
Кажете, че вашата мрежа сървърът се нарича PRODSERVER, трябва да добавите акаунта на машината/компютъра PRODSERVER$ към разрешенията на отдалечената споделена папка.
Надявам се, че това помага.

person frezq    schedule 11.08.2014