/Bin -ro,access = tiger:lion
/Users -rw,access = tiger
В данном случае доступ к первому каталогу разрешен любым системам, но только для чтения (-ro). Ко второму каталогу могут обращаться для чтения хосты tiger и lion, а к каталогу /users доступ для чтения и записи (-rw) разрешен системе tiger.
Сервер может экспортировать только собственные каталоги и не может разрешить экспорт каталогов, смонтированных на другом сервере NFS. Клиент может монтировать каталоги любого количества серверов. Разумеется, монтировать можно только каталоги, которые сервер разрешил использовать данному клиенту.
Клиент должен явным образом указать все монтируемые им каталоги удаленных серверов. Обычно это делается при выполнении последовательности команд монтирования во время запуска операционной системы клиента. Иногда команда mount читает специальный конфигурационный файл.
Команда монтирования может иметь необязательные параметры, среди которых наиболее важны те, что определяют:
■ Должен ли каталог иметь полномочия для чтения и записи или только для чтения.
■ Нужно ли периодически возобновлять попытки монтирования в фоновом режиме при неудаче монтирования во время запуска системы.
■ Требуется ли прерывать выполнение запроса RPC к NFS при длительном ожидании ответа.
■ Реализована ли в NFS одна из версий системы безопасности RPC.
Команда mount приводит к отправке на сервер запроса RPC с именем Add Mount Entry (добавить точку монтирования). В ответе на это сообщение протокол монтирования возвращает описатель файла, который клиент будет использовать для идентификации каталога в последующих запросах. Вспомним, что описателем является строка, содержащая идентификатор сервера и соответствующего каталога или файла. Например, когда происходит монтирование /users как локального каталога /usr, в ответе на запрос монтирования будет возвращен описатель файла для каталога /users.
15.15.1 Процедуры монтирования
Процедуры, поддерживающие программу mount на сервере, показаны в таблице 15.4.
Таблица 15.4 Процедуры монтирования
| Процедура | Описание |
| 0 | Null (пустая): Ответ указывает на активность программы. |
| 1 | Add Mount Entry (добавить точку монтирования): В список команды mount добавляется элемент для монтируемого удаленного каталога. |
| 2 | Return Mount Entries (возвратить точку монтирования): Возвращение клиенту текущего пути монтируемого каталога. |
| 3 | Remove Mount Entry (удалить точку монтирования): Удалить сведения о заданном каталоге. |
| 4 | Remove All Mount Entries (удалить все точки монтирования): Удалить всю информацию о монтировании удаленных каталогов. |
| 5 | Return Export List (возвратить список экспортируемых каталогов): Получить список каталогов и хостов, к которым разрешен доступ. |
В NFS требуется как можно большая независимость сервера. Сервер NFS должен хранить как можно меньше сведений о клиенте, чтобы при крахе клиента или сервера восстановление было простым и безболезненным.
Клиент знает, что сервер NFS берет на себя всю работу по обслуживанию запроса и выводу ответа. Однако часто NFS работает поверх протокола UDP, не обеспечивающего целостности информации. Что делать, если на запрос не приходит ответ? NFS просто повторяет запрос после интервала тайм-аута.
Иногда случается так, что исходный запрос попадает на сервер, но ответ на этот запрос теряется. Для таких случаев сервер NFS не придерживается полной независимости от клиента и кеширует самые последние ответы для вывода их на дублированные запросы.
На какие из запросов следует кешировать ответы? Некоторые операции (например, чтение или просмотр) являются равномощными (idempotent), т.е. при многократном выполнении они формируют тот же самый результат. Другие операции (например, удаление файла или создание каталога) — не являются равномощными. При потере исходного результата выполнение повторного запроса на операцию приведет только к бессмысленному сообщению об ошибке. Понятно, что кешировать следует операции, не являющиеся равномощными: это позволит NFS формировать корректный ответ на повторные запросы.
