nginx: openat() \".../www/site.ru.\" failed (1: Operation not permitted)

[cyrax]

В WinXP поставил VirtualBox и в качестве гостевой ОС установил Debian 8 (для разработки/отладки сайта)
Средствами VirtualBox корневую директорию сайта расшарил между гостевой ОС (Debian) и хост-машиной (WinXP). Т.е. физически все файлы сайта хранятся на хост-машине, а в гостевой ОС (Debian) эту директорию смонтировал в папку, которая является корнем сайта. Монтирование выполняется через виртуальную файловую систему vboxsf, согласно инструкции к VirtualBox:

Код Выделить Развернуть

sudo mount -t vboxsf -o uid=user,gid=user,dmode=755,fmode=644 site /home/user/www/site.ru
Монтирование выполняется нормально. Все изменения в этой директории, выполненные в гостевой машине, видны из хост-машины, и наоборот (двусторонний "шаринг"). nginx и php-процессы запускаются от пользователя user.

Проблема в том, что при запуске любой страницы, любого скрипта или любой html-ки из этой самой смонтированной директории получаем ошибку от nginx:

[crit] 467#467: *1 openat() "/home/user/www/site.ru." failed (1: Operation not permitted)

При этом в браузере страница продолжает ожидать ответа от веб-сервера (т.е. nginx после этой ошибки никакого ответа клиенту-браузеру не отдаёт) минуты 2-3, после чего в браузере отображается пустая страница, а в логах nginx никаких ошибок (например, по таймауту) не появляется. Ключевой проблемой здесь является ошибка openat() - Operation not permitted.

Проверил следующее:
1. Если из браузера запустить скрипт phpmyadmin, который физически расположен не в смонтированной директории, а в /usr/share/phpmyadmin/, то скрипт работает нормально, без каких-либо ошибок
2. Если корневую директорию сайта не монтировать, а просто создать в гостевой ОС директорию с файлами сайта, то тоже никаких проблем не наблюдается
3. Если запускать nginx от root и запрашивать статичный html-файл, возникает та же самая ошибка
4. Если выполнять монтирование с максимальными правами (указанные права выставляются на папки и файлы корректно - проверил), проблема сохраняется:

Код Выделить Развернуть

sudo mount -t vboxsf -o uid=user,gid=user,dmode=7777,fmode=7777 site /home/user/www/site.ru

Код Выделить Развернуть

sudo mount -t vboxsf -o uid=root,gid=root,dmode=7777,fmode=7777 site /home/user/www/site.ru
5. Если в гостевой ОС (Debian) попробовать изменять, удалять, корректировать файлы из смонтированной директории пользователем user, то никаких проблем с правами не наблюдается

Вопрос. С точки зрения гостевой ОС в чём может быть проблема ?
Очевидно, что проблема связана с монтированием в директорию гостевой ОС директории хост-машины (виртуальная файловая система vboxsf). Но ведь для гостевой ОС эта директория для всяких-разных (или не для всех ?) операций должна выглядеть как обычная родная директория. Или не так ?
Cообщение объединено 15 ноября 2016, 01:42:54
Вот здесь пишут, что такие монтирования веб-проектов выполняются наура, без проблем. И сайты нормально работают, проблем с доступом нет. Только ОС, конечно, другие, но принципиальных проблем в этом нет:

http://phpclub.ru/talk/threads/%D0%A2%D0%BE%D1%80%D0%BC%D0%BE%D0%B7%D0%B0-phpstorm-9.81280/page-2#post-736535
У меня сами проекты подмонтированы в гостевые OS через shared folders,
в отличие от smbfs, shared folders и быстрая, и поддерживает все фичи вроде atime, sendfile.
Код доступен хоть в виртуалке, хоть без, консольные задачи с загрузкой по памяти, процу или диску можно запустить и под виндой.

[endru]

Но ведь для гостевой ОС эта директория для всяких-разных (или не для всех ?) операций должна выглядеть как обычная родная директория. Или не так ?

не так. Это стандартная ошибка всех кто работает с шарами. Помимо сетевых прав на папку, есть еще и локальные права на папку. Вот и получается, к примеру
на винде файлы принадлежат ВасеПупкину, а по сети, при монтировании файлы, принадлежат какому то user. windows не знает кто такой user, а debian не знает кто такой ВасяПупкин, вот и вся проблема.

5. Если в гостевой ОС (Debian) попробовать изменять, удалять, корректировать файлы из смонтированной директории пользователем user, то никаких проблем с правами не наблюдается

Не могу быть уверен что вы делали все верно. В любом случае, любой разработчик знает, что в случае использования файлов из сетевой шары, возникают задержки, и они значительны. Протоколы обмена данными дают о себе знать.
Те кто разрабатывают сайты на виртуалках, обычно делают шары наоборот! Из гостевой ОС дают либо шару, либо FTP/SFTP доступ, и пользуются.

[cyrax]

не так. Это стандартная ошибка всех кто работает с шарами. Помимо сетевых прав на папку, есть еще и локальные права на папку. Вот и получается, к примеру
на винде файлы принадлежат ВасеПупкину, а по сети, при монтировании файлы, принадлежат какому то user. windows не знает кто такой user, а debian не знает кто такой ВасяПупкин, вот и вся проблема.

В данном случае, судя по всему, на хост-машине файлы создаются/меняются (при их создании/изменении в гостевой ОС) под тем пользователем, под которым работает VirtualBox (администратор). Независимо от того, какой пользователь соответствующие файлы создаёт/меняет в гостевой ОС. Т.к. с файлами (поступающими из гостевой ОС) в конечном счёте на хост-машине работает сам VirtualBox. Ну а в гостевой ОС работа с подмонтированными файлами идёт как обычно - согласно правам пользователя и правам, указанным при монтировании (опция -o утилиты mount).

К такому выводу я пришёл в итоге ночных "экспериментов". Как оказалось, схема работы с общими папками, описанная в 1 посте, - работает нормально. Без всяких проблем и ошибок. А причина сабжевой проблемы - мелкая ошибка, допущенная в конфиге nginx. А именно: для безусловного перехода на именованный location я использовал такую конструкцию:

Код Выделить Развернуть

try_fyles . @gateway;
Логика здесь такая: проверяется файл ".", и если его не существует, управление передаётся в именованный location gateway. Поскольку файла "." существовать не может (текущая директория под это имя не попадает - ни в Win, ни в Linux), то переход в gateway осуществляется всегда.

Но в этой конструкции была допущена ошибка: вместо "." нужно использовать "/.", т.к. uri всегда начинается со слэша.
В случае с "." проверялся файл "site.ru.", а не "site.ru/.". И вот на проверке файла "site.ru." VirtualBox на WinXP (а вернее, виртуальная файловая система vboxsf) блокировала доступ (ошибка nginx openat() \".../www/site.ru.\" failed (1: Operation not permitted). Правда, не понятно, почему, т.к. Linux ничего не блокирует, в Linux просто такого файла не существует.

При этом в браузере страница продолжает ожидать ответа от веб-сервера (т.е. nginx после этой ошибки никакого ответа клиенту-браузеру не отдаёт) минуты 2-3, после чего в браузере отображается пустая страница, а в логах nginx никаких ошибок (например, по таймауту) не появляется. Ключевой проблемой здесь является ошибка openat() - Operation not permitted.

А здесь происходило следующее: nginx после генерации в своих логах этой ошибки нормально передавал запрос fastcgi-серверу и сознательно ждал ответа. Но пока fastcgi-сервер обрабатывал запрос (2-3 минуты), я уже успевал переименовать папку с сайтом (экспериментировал: менял местами рабочий сайт и тестовые скрипты - путём их переименования) - это приводило к критической ошибке fastcgi-сервера (не найдены требуемые скрипты), в результате которой браузер получал пустую страницу с 500 ошибкой (через 2-3 минуты).

А почему fastcgi-сервер работал так долго (2-3 минуты) - потому что при первой (после очистки кэша) загрузке страниц сайта генерировался объёмный кэш + виртуальная машина частично сидела в свопе + операции с файлами выполнялись медленнее из-за того, что директория сайта была расшарена с хост-машиной.

P.S. Кстати, вы тоже не обратили внимания на эту самую точку - в сообщении об ошибке openat.
А ведь всё было на поверхности. Далеко нам до Холмса...
Cообщение объединено 15 ноября 2016, 22:31:20

В любом случае, любой разработчик знает, что в случае использования файлов из сетевой шары, возникают задержки, и они значительны. Протоколы обмена данными дают о себе знать.

Задержки по сравнению с использованием нативных файлов ОС. В данном случае вместо нативных файлов используются виртуальные файлы гостевой ОС. Т.е. изначально имеют место издержки на виртуализацию. А когда мы расшариваем папку, общую с хост-машиной, физически файлы хранятся на хост-машине, а на хост-машине как-раз таки файлы являются нативными. Операции с нативными файлами всегда будут быстрее операций с виртуальными файлами.

Вопрос в том, как VirtualBox организовывает работу таких общих папок. Если виртуализация в гостевой ОС таких файлов полностью сохраняется, и сюда плюс накладывается расходы на шаринг, то будет работать медленнее. Если такие общие файлы обходят (хотя бы частично) виртуализацию в гостевой ОС, то должно работать быстрее.

Вот здесь пишут:

http://phpclub.ru/talk/threads/%D0%A2%D0%BE%D1%80%D0%BC%D0%BE%D0%B7%D0%B0-phpstorm-9.81280/page-2#post-736535
У меня сами проекты подмонтированы в гостевые OS через shared folders,
в отличие от smbfs, shared folders и быстрая, и поддерживает все фичи вроде atime, sendfile.
Код доступен хоть в виртуалке, хоть без, консольные задачи с загрузкой по памяти, процу или диску можно запустить и под виндой.