Estou trabalhando em um site executando o Sitecore 6.3.1 em uma instância do Windows Server 2008 R2.
Tudo estava funcionando perfeitamente até que copiei alguns arquivos estáticos (CSS, JS, imagens) de um arquivo ZIP fornecido por um de nossos desenvolvedores frontend para C:\Inetpub\wwwroot\(website name)\Website\static .
Agora, sempre que tento acessar qualquer um desses arquivos estáticos (por exemplo, http://localhost/static/css/main.css ), recebo um erro 401.3 (de acordo com C:\inetpub\logs\LogFiles\W3SVC2\u_ex110216.log ).
O próprio aplicativo Sitecore está funcionando bem, e os arquivos estáticos estavam perfeitamente acessíveis até que eu os substituísse pelos arquivos atualizados.
De acordo com todos os recursos que encontrei sobre o assunto, um erro 401.3 indica que a ACL do recurso solicitado não está permitindo o acesso à conta de usuário do IIS.
Analisei a ACL de um arquivo que está atualmente em funcionamento (por exemplo, C:\Inetpub\wwwroot\(website name)\Website\default.css ) e parece ser idêntico ao dos arquivos estáticos que estão inacessíveis.
Eu verifiquei as configurações do pool de aplicativos para o site do Sitecore e o usuário anônimo é "IUSR". Seguindo as instruções em este tópico , dei à conta IUSR permissões de leitura e execução para o diretório C:\Inetpub\wwwroot\(website name)\Website\static e apliquei-a recursivamente para todas as subpastas e arquivos nesse diretório. Sem dados.
Com base nas sugestões oferecidas neste tópico , tentei remover completamente o diretório static e recriar ele e seus subdiretórios manualmente para que herdam as permissões do diretório pai Website . No entanto, o problema persistiu.
O que mais posso tentar resolver esses erros 401.3?
Eu descobri o que estava causando o problema:
Acontece que o atributo "Criptografar conteúdo para proteger dados" foi definido para cada um dos arquivos.
Eu acessei as propriedades de cada arquivo e desmarquei essa caixa de seleção (clique com o botão direito - > Propriedades - > Avançado ... (ao lado de Atributos) - > desmarque Encriptar conteúdo para proteger os dados) e tudo está de volta normal.
Eu tive um problema semelhante com meu site no Windows Server 2008:
Para testar, usei duas páginas:
hello.html hello.aspx hello.aspx ficou muito bem. hello.html jogou um 401.3 sem autorização. A Microsoft processou o comando "ACCESS DENIED" em hello.html pelo usuário do pool de aplicativos quando tentei navegar para a página.
Para resolver o problema, adicionei o usuário IUSR à lista de controle de acesso da pasta do site. A IUSR não está listada na lista de usuários da ferramenta de gerenciamento do Windows, mas aparece se você a procurar ao adicionar um usuário na guia de segurança de propriedades da pasta.
Eu achei muito estranho (e confuso) que o procmon relatou que o usuário tentando acessar hello.html era o usuário do pool de aplicativos , e não o iusr.
Eu tive um problema semelhante hoje, e o que consertou para mim foi seu segundo ponto sobre dar à conta IUSR permissão para ler e modificar os arquivos e diretórios (não eram apenas os arquivos estáticos com os quais eu estava lidando)
Verifique se a identidade do pool de aplicativos tem permissões no site e nos serviços de rede.