Каков механизм монтирования CIFS «только для чтения»?

Необходимо улучшить объем записей в регулярном выражении. Захват (. *) поглотит все и жадный. В записи можно использовать ленивый квантификатор (например, (. *?) ) или класс символов, исключающий разделяющий / (например, ([^/] +) ).

Например, чтобы реализовать эти три случая как отдельные правила:

location ~ ^/page/([^/]+)/([^/]+)/([^/]+) {
    try_files $uri /page/index.php?site=$1&id=$2&args=$3;
}
location ~ ^/page/([^/]+)/([^/]+) {
    try_files $uri /page/index.php?site=$1&id=$2;
}
location ~ ^/page/([^/]+) {
    try_files $uri /page/index.php?site=$1;
}

Регулярные выражения вычисляются по порядку до тех пор, пока не будет найдено совпадение, поэтому более конкретное правило должно быть помещено перед менее конкретным правилом. Кроме того, все они должны быть размещены после блока location ~\.php $ , в противном случае ваши URI PHP нарушатся.

См. этот полезный ресурс о синтаксисе регулярных выражений.

Я не уверен, что это правильный ответ в более широком смысле, но в той степени, в какой он решает мою проблему, он есть.

Обсуждения и рекомендации в этом потоке и в других предыдущих ( LDAP/Samba/autofs i.a.) заставили меня пересмотреть свой подход. Я пытался настроить локальную сеть, состоящую из клиентов MacOS и серверов Unix/Linux, с центральным сервером LDAP для аутентификации, SSH-доступом от машины к машине, некоторыми общими сетевыми файловыми системами и автофами . Это было вызвано частично отказом Apple от MacOS Server, а также (для меня - необъяснимым) переходом Apple в SMB. Более насущной необходимостью было воссоздать рабочую инфраструктуру для резервного копирования Time Machine для клиентов Mac OS, которые терпели неудачу из-за использования Apple их SMBX диалекта SMB, который не поддерживается в Synology NAS, на котором должны были храниться резервные копии TM.

Чем дальше я получал, тем больше Windows crud появлялся в моей сети, в которой вообще нет Windows-машин. Вся моя сетевая архитектура была продиктована Active Directory, к чему меня неумолимо подталкивали. Учитывая, что файловые системы Windows - это ужасное совпадение (в чисто структурном смысле) для MacOS и Unix/Linux в любом случае, использование SMB просто по словам Apple - так вдруг оказалось нелепым. Самба - удивительный предмет программного обеспечения, но «нельзя делать шелковый кошелек из свиноматочного уха», как есть в старой поговорке.

Поэтому я начал заменять SMB на NFSv4. Теперь у меня есть сетевая файловая система, которая соответствует моим файловым системам MacOS и Unix/Linux, и я добился большего прогресса за последние три дня, чем за предыдущие три месяца.

У меня все еще есть проблема предусматривать сетевого доступа для резервных копий Time Machine, но я сделаю это, подключив диски к Mac Mini (который был моим традиционным сервером и теперь имеет время на руках) и позволив реализации Apple SMB справиться с тем, что является чисто проблемой Apple.

Я пытался использовать SMB, потому что шум, который я услышал от Apple, и сеть была в том, что это было действительно единственное шоу в городе. Apple отказывалась от поддержки AFP (который в любом случае не работает на Unix/Linux - но тогда и SMB тоже); и NFS, по всей видимости, был слишком небезопасен.Вполне возможно, что взлом вместе решения SMB был бы еще более небезопасным, если бы оно даже работало. Надеюсь, пока я решил свою проблему.

Даже если это неверный ответ: -)

Действительно.

Когда клиент монтирует экспорт только для чтения, он не должен отправлять запросы на запись на файловый сервер.
Это делает маловероятным, что коррупция пришла с вашего конца. Но поскольку это состояние только для чтения устанавливается на клиенте и не принудительно выполняется с файлового сервера, предоставляющего экспорт, нельзя полностью исключить, что клиент (не обязательно ваш) получил доступ к общему ресурсу в режиме чтения-записи и является виновником.

Обратите внимание, что также тот факт, что файл находится на экспорте, не исключает, что повреждение произошло и на самом файловом сервере.