Сервер IIS: каталог не доступен для записи по символической ссылке по сравнению с переходом каталога (только для первого пользователя)
У нас есть следующие настройки для веб-сервера: Windows Server 2008 R2 Standard, IIS 7.5.7600.16385, PHP 5.3.28, используемая нами среда HMVC - Kohana.
Kohana нужен каталог кеша для записи в D:\inetpub\www\application\cache (D:\inetpub\www\ это наш webroot). Мы удалили каталог кеша в этом месте и создали символическую ссылку на каталог вне webroot: D:\cache, который доступен для записи.
Похоже, что первый пользователь, который посещает веб-сайт, получает ошибку "каталог кэша недоступен для записи", что является ошибкой, вызываемой Kohana, к удивлению, когда у него нет разрешения на запись в каталог. Второй, третий и т. Д. Пользователи не получают эту ошибку. Странно то, что только этот первый пользователь продолжает получать эту ошибку, в то время как другие никогда не видят ее.
Решением для нас было использование соединения каталогов.
Я прочитал много документации о различиях между символической ссылкой и соединением каталогов, но я не могу связать это с ошибкой, которую мы получили. Единственное, о чем я могу думать, это тот факт, что символическая ссылка обрабатывается на стороне клиента, а соединение - на стороне сервера.
Комментарий Гарри Джонстона в этом посте указывает на две новые ссылки, но там мы не смогли найти хорошее объяснение нашей проблемы.
@ Да, тот факт, что символические ссылки пересекают SMB, задокументирован в разделе "Что нового в SMB?". Я не знаю ни одной документации, в которой явно говорится, что точки соединения этого не делают, но это присуще способу их реализации, и я нашел " Создание точки соединения корневых и промежуточных областей SYSVOL", которая в противном случае не работала бы. (В основном, это просто опыт.)
Обновить:
Я контролировал каталоги в мониторе процесса и получил следующий результат:
Пользователь: Test2, первый пользователь (здесь я получил ошибку)
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
Пользователь: Test3, второй пользователь (здесь я не получил ошибку)
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
Кто-нибудь знает, почему первый пользователь не может писать в каталог, когда мы используем символическую ссылку вместо соединения каталога?