Вики IT-KB
Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Работа с сетевыми ресурсами по протоколу NFS в macOS
Поддержка протокола NFS в macOS принципиально ничем не отличается реализаций на базе Linux. В каждой macOS уже есть встроенный NFS клиент и сервер, который включен в конфигурации по умолчанию.
Для того, чтобы сделать каталог общедоступным, необходимо создать конфигурационный файл /etc/exports . В этом файле следует перечислить локальные каталоги, для которых мы хотим разрешить доступ из сети, а также обозначить параметры предоставления общего доступа.
В данном примере каталог Projects на съёмном накопителе Files будет доступен для всех пользователей сети в режиме чтения.
Начиная с macOS 10.14 (Mojave), демону nfsd необходимо разрешить работу с диском. В противном случае он не сможет получить доступ к этому диску. Предоставить такой доступ можно через:
«Настройки» → «Защита и безопасность» → «Конфиденциальность» → «Доступ к диску».
Здесь следует добавить исполняемый файл /sbin/nfsd .
Такую же операцию необходимо выполнить и для брандмауэра, если он включен.
Выполним перезапуск демона nfsd:
Теперь поговорим о настройке NFS-клиента.
Чтобы всякий раз не выполнять подключения NFS-шары вручную (⌘+K), можно настроить механизм автоматического монтирования.
Создадим конфигурационный файл:
Разберёмся с точкой монтирования и ключами:
Имя удалённого каталога не может быть на кириллице, иначе automount не сможет смонтировать каталог.
В заключении отредактируем конфигурационный файл /etc/auto_master , добавив в конец этого файла подключаемый конфиг автомонтирования NFS
Для проверки автомонтирования выполним:
Теперь при каждой перезагрузке macOS NFS-шара будет автоматически монтироваться для любого пользователя.
Проверено на следующих конфигурациях:
| Версия ОС |
|---|
| Apple macOS High Sierra (10.13) |
| Apple macOS Mojave (10.14) |
| Apple macOS Catalina (10.15) |
Автор первичной редакции:
Виталий Якоб
Время публикации: 24.03.2020 13:11
Mac os подключение к nfs
Задача: монтировать nfs-ресурсы в макоси.
В принципе, в макоси уже встроена поддержка nfs и соответствующие сетевые ресурсы можно монтировать через Finder (⌘K), однако чтобы это работало для обычного юзера, требуется некоторое шаманство на стороне linux-сервера.
И заодно важный момент: я монтирую только на чтение, поскольку если разрешить запись, то макось загадит диск своими служебными файлами.
На линукс-машине в /etc/exports прописываем что-то вроде:
Здесь адрес 192.168.13.12 — это айпишник макосной машины. После чего в Finder стандартным образом (через ⌘K или меню Go → Connect to Server. ) монтируем ресурс, адрес указываем в виде nfs://nfs-server.name/home/user/downloads .
Опция insecure как раз и нужна, чтобы можно было простым юзером монтировать, без неё будет выдаваться маловразумительная ошибка.
Ещё одна вредная и очень трудноуловимая проблема связана с макосной интерпретаций кодирования «составных» букв в именах файлов, например, «й» или «ё», или «ü». Если имя файла (или вообще где-то в пути до файла встречается) содержит такую букву, то файл просто не откроется, причём с невразумительной ошибкой типа “The application can’t be found.” Я в детали не хочу вдаваться, можете сами погуглить по ключевым словам “mac os x nfc nfd unicode”.
Решение достаточно простое: нужно изменить опции монтирования nfs-ресурсов по умолчанию, для этого добавьте в файл /etc/nfs.conf такую строчку:
Теперь можно монтировать через Finder и всё будет в порядке.
Ну и команда для всяких тестов, вдруг пригодится:
Включение общего доступа к сетевому (NFS) в Mac OS X
Автор:
Support
Проблема
NFS — лучший способ обмена файлами и папками через сеть между рабочими станциями Mac и Linux.
В этой статье представлены инструкции по созданию в ОС Mac OS X 10.5 или более поздней версии системы с общим доступом.
Решение
В этом примере мы сделаем папку /Users на компьютере Mac доступной для других компьютеров в сети.
- Откройте окно терминала в папке /Applications/Utilities .
- Введите следующую команду для редактирования файла /etc/export :
sudo nano /etc/export - При появлении запроса введите пароль.
- Добавьте строку в файл, как показано в следующем примере (измените IP-адрес и сделайте маску, используя адрес, используемый в сети. Обратитесь к сетевому администратору за этой информацией.):
/Users -network 192.168.0.0 -mask 255.255.0.0 - Нажмите CTRL+o, а затем ENTER для сохранения файла.
- Нажмите CTRL+x для выхода из текстового редактора.
- Введите следующую команду, чтобы включить nfsd :
включение и отключение - Введите следующую команду, чтобы проверить, что общий доступ включен правильно.:
Shotionmode -e
Результат выполнения этой команды должен быть аналогичен приведенным ниже:
/Users Everyone
Linux or Mac computer on your network should be able to be able to place the
/Users directory on this Mac.
(В Linux используется команда сборки -t nfs или автоматический ограничитель amd . В другом Mac откройте Finder, нажмите SHIFT+CTRL+G и введите /net/ /Users ).
oleksii
oleksii Тайный дзен-буддист-революционер-провокатор-вовсе-не-кот
У мака другая нумерация юзеров (uid 501 для первого юзера, а в linux uid 1000), и потому надо в параметрах экспорта конфига NFS сервера указать: insecure,all_squash,anonuid=1000,anongid=1 000 (два часа маялся с этой траблой).
А если для удобства работы с тестовой системой нужен удобный рутовый доступ, то можно указать так (файл /etc/exports):
/ 192.168.1.0/255.255.255.248(rw,async,insecure,all_squash,anonuid=0,anongid=0)
(« / — расшариваем корень», «192.168.1.0/255.255.255.248» — моя локальная подсеть)
А после не забываем сделать:
sudo exportfs -ra
Теперь возвращаемся за мак, Finder → Подключение к серверу → nfs://имя_сервера/ (или nfs://IP_сервера/).
Enjoy 🙂
Что-то не получается так.
На команду
mount -t nfs -o nolock 192.168.1.10:/tmp/usbmounts/sdb1 /Users/andreikalabuhov/NFS
приходит ответ:
mount_nfs: can’t mount /tmp/usbmounts/sdb1 from 192.168.1.10 onto /Users/andreikalabuhov/NFS: Operation not permitted
На медиа-плеере с адресом 192.168.1.10 делаю предварительно команду:
exportfs -o rw,insecure,no_root_squash,no_subtree_ch eck *:/tmp/usbmounts/sdb1
Блин, 3 года назад было дело, уже с трудом вспоминаю 🙂
Если NFS сервер на линуксе а коннектимся к нему с мака то нужно при настройке nfs сервера явно указывать all_squash,anonuid=1000,anongid=1000.
Попробуй что-то типа такого: exportfs -o rw,insecure,no_subtree_check,all_squash,a nonuid=1000,anongid=1000 *:/tmp/usbmounts/sdb1
Использование all_squash вполне приемлимо так как для медиаплеера обычно нет смысла разделения прав по юзерам которые к нему подключаются по NFS.
Чтобы стало понятнее почему так, вкратце по опциям:
root_squash
Map requests from uid/gid 0 to the anonymous uid/gid. Note that this does not apply to any other uids or gids that might be equally sensitive, such as user bin or group staff.
no_root_squash
Turn off root squashing. This option is mainly useful for diskless clients.
all_squash
Map all uids and gids to the anonymous user. Useful for NFS-exported public FTP directories, news spool directories, etc. The opposite option is no_all_squash, which is the default setting.
anonuid and anongid
These options explicitly set the uid and gid of the anonymous account. This option is primarily useful for PC/NFS clients, where you might want all requests appear to be from one user. As an example, consider the export entry for /home/joe in the example section below, which maps all requests to uid 150 (which is supposedly that of user joe).
Интересно. А почему 1000, а не 0 ?
Понял в чем вопрос. Если нужен рутовый доступ к NFS то, конечно, указываем 0 (id рута). Но для медиацентра такое, думаю, не нужно.
А если хотим анонимно заходить на NFS, но как будто из из под обычного юзера, то надо указать его id в anonuid и anongid. Я брал id 1000 как первый возможный id который может быть у обычного юзера (если NFS сервер на линуксе).
B6. Why is the «async» export option unsafe, and is that really a serious problem?
A. The biggest problem is not just that it is unsafe, but that corruption may not be detected.
In the Linux implementation of NFS Version 2, when the «async» export option is in effect, a Linux NFS server may crash before posting all NFS write requests to disk. A Version 2 client, however, always assumes data is permanently written to stable storage, and that it is safe to discard buffers containing the written data.
After a server crash, the Version 2 client cannot know that unwritten data is lost; this is why Version 2 writes are supposed to be permanent before the server replies. Even if a client still has the modified data in its cache, the data on the server no longer matches what is cached on the client (since some or all of the writes did not complete before the server crashed). This may cause applications to make future decisions based on data cached by the client rather than what is on the server, thus further corrupting the file.
For the Linux implementation of NFS Version 3, using the «async» export option to allow faster writes is no longer necessary. NFS Version 3 explicitly allows a server to reply before writing data to disk, under controlled circumstances. It allows clients and servers to communicate about the disposition of written data so that in the event of a server reboot, a Version 3 client can detect the reboot and resend the data.
In summary, be sure all exports on your Linux NFS servers use the «sync» option by setting it explicitly or by upgrading your nfs-utils package to version 1.0.1 or later. If you need fast writes, be sure your clients mount using NFS Version 3. You may also improve write performance by adding the «wdelay» option to your exports.
Если NFS Version 2 то использовать только sync, иначе может быть незамеченное повреждение файлов при записи.
А NFS Version 3 в любом случае использует механизмы асинка, но безопасно. Так что указывать async тоже смысла нет.
Корче да, async опция безполезная и даже вредная.