Servidor IIS: diretório não gravável via link simbólico comparado à junção de diretório (somente para o primeiro usuário)

1

Temos a seguinte configuração para um servidor da Web: Windows Server 2008 R2 Standard, IIS 7.5.7600.16385, PHP 5.3.28, a estrutura do HMVC que usamos é Kohana .

Kohana precisa de um diretório de cache para ser gravável em D:\inetpub\www\application\cache ( D:\inetpub\www\ é nosso webroot). Removemos o diretório de cache neste local e criamos um link simbólico para um diretório fora da webroot: D:\cache , que é gravável.

Parece que o primeiro usuário que está visitando o site recebe o erro "O diretório de cache não é gravável", o que é um erro que Kohana dispara, surpreendentemente, quando ele não tem permissão para escrever no diretório. O segundo, terceiro e assim por diante, os usuários não recebem esse erro. O estranho é que apenas esse primeiro usuário está recebendo esse erro, enquanto os outros nunca o veem.

A solução para nós foi usar uma junção de diretório .

Eu leio um lote de documentação sobre as diferenças entre um link simbólico e uma junção de diretório , mas não consigo relacionar nada com o erro que recebemos. A única coisa que posso pensar é o fato de que um link simbólico é processado no lado do cliente, enquanto uma junção é processada no lado do servidor.

O comentário de Harry Johnston em esta postagem aponta para dois novos links , mas não encontramos uma boa explicação para o nosso problema.

@Daan the fact that symbolic links cross SMB is documented in What's new in SMB?. I don't know of any documentation that explicitly states that junction points don't, but it is inherent in the way they are implemented and I did find Create the SYSVOL Root and Staging Areas Junction Point which otherwise wouldn't work. (Mostly though, it's just experience.)

Atualização:

Eu monitorei os diretórios no monitor de processo e obtive o seguinte resultado:

Usuário: Test2, primeiro usuário (aqui recebi o erro)

10:21:52.7311891 AM php-cgi.exe QueryOpen           D:\inetpub\www\application\cache    SUCCESS             CreationTime: 8/28/2015 5:12:56 PM, LastAccessTime: 8/28/2015 5:12:56 PM, LastWriteTime: 8/28/2015 5:12:56 PM, ChangeTime: 8/28/2015 5:12:56 PM, AllocationSize: 0, EndOfFile: 0, FileAttributes: DRP
10:21:52.7313164 AM php-cgi.exe CreateFile          D:\inetpub\www\application\cache    SUCCESS             Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NL-COMPUTER1\Test2, OpenResult: Opened
10:21:52.7313552 AM php-cgi.exe QuerySecurityFile   D:\inetpub\www\application\cache    BUFFER OVERFLOW     Information: Owner, Group, DACL
10:21:52.7313725 AM php-cgi.exe CloseFile           D:\inetpub\www\application\cache    SUCCESS 
10:21:52.7314490 AM php-cgi.exe CreateFile          D:\inetpub\www\application\cache    SUCCESS             Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NL-COMPUTER1\Test2, OpenResult: Opened
10:21:52.7314729 AM php-cgi.exe QuerySecurityFile   D:\inetpub\www\application\cache    SUCCESS             Information: Owner, Group, DACL
10:21:52.7314867 AM php-cgi.exe CloseFile           D:\inetpub\www\application\cache    SUCCESS 

Usuário: Test3, segundo usuário (aqui eu não recebi o erro)

10:28:01.7973266 AM php-cgi.exe 5220    QueryOpen           D:\inetpub\www\application\cache    SUCCESS CreationTime: 8/28/2015 5:12:56 PM, LastAccessTime: 8/28/2015 5:12:56 PM, LastWriteTime: 8/28/2015 5:12:56 PM, ChangeTime: 8/28/2015 5:12:56 PM, AllocationSize: 0, EndOfFile: 0, FileAttributes: DRP
10:28:01.7974467 AM php-cgi.exe 5220    CreateFile          D:\inetpub\www\application          SUCCESS Desired Access: Read Data/List Directory, Synchronize, Disposition: Open, Options: Directory, Synchronous IO Non-Alert, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NL-COMPUTER1\Test3, OpenResult: Opened
10:28:01.7974702 AM php-cgi.exe 5220    QueryDirectory      D:\inetpub\www\application\cache    SUCCESS Filter: cache, 1: cache
10:28:01.7974943 AM php-cgi.exe 5220    CloseFile           D:\inetpub\www\application          SUCCESS 
10:28:01.7975657 AM php-cgi.exe 5220    CreateFile          D:\inetpub\www\application\cache    SUCCESS Desired Access: Generic Read, Disposition: Open, Options: Synchronous IO Non-Alert, Open Reparse Point, Attributes: n/a, ShareMode: None, AllocationSize: n/a, Impersonating: NL-COMPUTER1\Test3, OpenResult: Opened
10:28:01.7976098 AM php-cgi.exe 5220    FileSystemControl   D:\inetpub\www\application\cache    SUCCESS Control: FSCTL_GET_REPARSE_POINT
10:28:01.7976285 AM php-cgi.exe 5220    CloseFile           D:\inetpub\www\application\cache    SUCCESS 
10:28:01.7977090 AM php-cgi.exe 5220    CreateFile          D:\cache                SUCCESS Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NL-COMPUTER1\Test3, OpenResult: Opened
10:28:01.7977524 AM php-cgi.exe 5220    QuerySecurityFile   D:\cache                BUFFER OVERFLOW Information: Owner, Group, DACL
10:28:01.7977657 AM php-cgi.exe 5220    CloseFile           D:\cache                SUCCESS 
10:28:01.7978337 AM php-cgi.exe 5220    CreateFile          D:\cache                SUCCESS Desired Access: Read Control, Disposition: Open, Options: Open Reparse Point, Attributes: n/a, ShareMode: Read, Write, Delete, AllocationSize: n/a, Impersonating: NL-COMPUTER1\Test3, OpenResult: Opened
10:28:01.7978573 AM php-cgi.exe 5220    QuerySecurityFile   D:\cache                SUCCESS Information: Owner, Group, DACL
10:28:01.7978703 AM php-cgi.exe 5220    CloseFile           D:\cache                SUCCESS 

Alguém sabe por que o primeiro usuário não pode escrever no diretório quando usamos um link simbólico em vez de uma junção de diretório?

    
por Daan 15.09.2015 / 10:32

0 respostas