Отображение идентификатора пользователя с NFS на Synology NAS

У меня есть устройство Synology NAS (работает под управлением DSM 5.1), и я экспортировал каталог через NFS. Я пытаюсь установить его на свою коробку Ubuntu.

В основном это работает нормально, но у меня проблемы с отображением пользователей и групп. На Ubuntu box, я uid 1000 (Роджер), Гид 1000 (Роджер). В Synology у меня uid 1026 (роджер), группа 100 (пользователи).

Если я использую NFSv3, он использует числовые значения uid / gid, что означает, что право собственности нарушено в Synology.

Если бы я когда-либо получал доступ к монтированию NFS только из той же коробки Ubuntu, используя одного и того же пользователя, это было бы хорошо, но я также обращался к каталогу из коробки Windows, используя CIFS (SMB), что означает, что разрешения неправильно.

Если я использую NFSv4 ( mount -o nfsvers=4) с настройками по умолчанию в Synology, то файлы, принадлежащие roger.usersSynology, отображаются как принадлежащие roger.usersпри просмотре из окна Ubuntu. Это хорошо.

Однако, когда я touchфайл:

roger@ubuntu$ touch /mounts/diskstation/music/foo

В конечном итоге он принадлежит 1000.1000Synology и отображается как принадлежащий nobody.4294967294при просмотре из окна Ubuntu.

Все, что я могу найти в теме на форумах Synology, датировано 2011 годом, когда NFSv4 не поддерживался, или состоит из людей, которые задают тот же вопрос и затем сдаются.

Для полноты, /etc/exportsимеет:

/volume1/music  10.0.0.0/24(rw,async,no_wdelay,root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

... и я монтирую его на коробку Ubuntu с помощью:

mount -t nfs diskstation:/volume1/music /mounts/diskstation/music/ -o rw,nfsvers=4

Я обнаружил некоторые намеки на то, что это sec=sysможет быть проблемой: почему отображение uid / gid в NFSv4 не работает с AUTH_UNIX (AUTH_SYS) , но это не имеет решения.

Есть ли простой способ обойти эту проблему? Есть ли более сложный ( кашель Kerberos кашель ) способ решить эту проблему?

Серьезно, если Kerberos - ответ, я приму этот удар, но я хотел бы знать, прежде чем тратить на это кучу времени.

Обновление : хотя в документации Synology говорится о различных параметрах Kerberos, я не могу найти их в пользовательском интерфейсе. В примечаниях к выпуску указывается «Если реализована защита Kerberos ...». Я нашел (но не могу найти снова) страницу, которая подразумевает, что она может отсутствовать на некоторых моделях. У меня DS211, в соответствии с информацией о системе. Может мне не повезло?

Для правильной работы сопоставления идентификаторов NFSv4 на клиенте и сервере должен быть запущен idmapdдемон идентификатора идентификатора, и он должен быть Domainнастроен в /etc/idmapd.conf.

Таким образом, ваш клиент NFS отправляет свои учетные данные идентификатора, как roger@example.comв командах NFS на проводе, а ваш IDM-сервер NFS-сервера отображает их пользователю, вызванному rogerна NFS-сервер. UID и GID не имеют значения, они отображаются в каждой системе idmapper.

Однако я не беспокоюсь об этом в моей Synology. Моя общая папка имеет следующие разрешения:

• права доступа
  • Локальные пользователи
    • Admin = чтение / запись
• Разрешения NFS
  • Сквош
    • Сопоставить всех пользователей с админом

В результате anonuid=1024,anongid=100( adminпользователь и usersгруппа) будут добавлены в экспорт /etc/exportsна NAS.

Мой NFS-клиент (на котором не работает ID Mapper) отправляет мои NFS-команды от имени моего пользователя ( 1000:1000), и, поскольку UID и GID не существуют на NAS, он переводит мои UID и GID, 1024:100поэтому меня рассматривают как Пользователь с правами администратора.

Это ужасно непрофессиональное и небезопасное использование NFS для бизнес-среды, но только для меня, чтобы получить доступ к своим файлам дома, это злоупотребление поведением NFS, которое приемлемо для меня.

Другой вариант - сделать rogerUID и GID одинаковыми на клиенте NFS и NAS, после чего вы можете использовать NFSv4 без сопоставления идентификаторов или использовать NFSv3, который опирается только на UID и GID.

Я действительно боролся с точно такой же проблемой. Я прошел через огромную боль в настройке сервера Kerberos с Docker на Synology, настроил отображение идентификаторов, и мне все еще не нравилось такое поведение. Kerberos слишком перегружен и его трудно поддерживать при перезагрузках и автонастройке. Кроме того, по умолчанию umask для вновь создаваемых файлов был 0000, и каждый новый файл создавался в режиме 777, независимо от того, какой был мой локальный umask.

Мое решение было похоже на решение suprjami, но я взял его немного дальше:

• Создайте нового пользователя с помощью веб-интерфейса Synology, назовите его примерно так roger.remote. Сделайте то же самое для группы пользователей и назовите ее так же, как имя пользователя.
• В Synology от имени root отредактируйте / etc / passwd и измените roger.remoteUID на 1000, а GID на 1000
• отредактируйте / etc / group и измените группу roger.remoteна 1000
• В веб-интерфейсе Synology установите для сквоша значение «все пользователи для администратора» и сохраните
• Как пользователь root, отредактируйте файл / etc / exports и измените UID / GID на anonuid=1000,anongid=1000
• Перезапустите NFS с помощью /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• Это тоже немного глупо - но chmod 777 /volume1. У меня было много странных проблем с моим домашним каталогом. KDE не запустится, потому что access()функция glibc вернет отказ в доступе к смонтированному каталогу NFS. (Но любые подкаталоги будут работать). У Firefox также была похожая проблема, когда он отказывался сохранять файлы в смонтированном каталоге из-за проверки доступа. Хотя разрешения были правильными, и я мог коснуться / создать / записать файлы в смонтированном каталоге. Изменение каталога parent / volume1 на доступный для записи мир исправило эту глупую проблему и обмануло клиентские приложения для записи в нее.
• Удалите все ACL файловой системы из общего ресурса. Путем множества случайных экспериментов я обнаружил, что эти списки ACL вызывают проблемы с маской режима созданных файлов. Я не мастер ACL, так что, возможно, есть более элегантное решение. Как root на Synology, делайте synoacltool -del /volume1/myshare. Вы должны увидеть +символ, удаленный из вывода ls -l.
• Измените владельца общего ресурса на нового пользователя: chown roger.remote:roger.remote /volume1/myshare
• Измените режим на 755: chmod 755 /volume1/myshare
• Смонтируйте том на клиенте, протестируйте разрешения, все должно работать! Обязательно коснитесь файла и убедитесь, что ваш bash umask применяется правильно.

$ umask 
0002
$ cd / mnt / myshare
сенсорный тест
тест $ ls -l
-rw-rw-r-- 1 Роджер Роджер 0 окт 21 18:15 тест

На Synology вы должны увидеть:

# ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 окт 21 18:15 тест

Наслаждайтесь!