Позначення ідентифікатора користувача за допомогою NFS в Synology NAS

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

В основному це добре працює, але у мене виникають проблеми із відображенням користувачів та груп. У вікні Ubuntu я uid 1000 (roger), gid 1000 (roger). У програмі Synology у мене є uid 1026 (roger), група 100 (користувачі).

Якщо я використовую NFSv3, він використовує числові значення uid / gid, а це означає, що право власності переплутано в Synology.

Якби я коли-небудь отримував доступ до монтажу NFS з того самого поля Ubuntu, використовуючи того самого користувача, це було б добре, але я також отримую доступ до каталогу з вікна Windows, використовуючи CIFS (SMB), що означає, що дозволи неправильно.

Якщо я використовую NFSv4 ( mount -o nfsvers=4) із налаштуваннями за замовчуванням у Synology, тоді файли, які належать roger.usersу Synology, з'являються у власності, 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 є відповідь, я буду вважати , що удар, але я хотів би знати , перш ніж витрачати купу часу на нього.

Оновлення : хоча документація Synology розповідає про різні варіанти Kerberos, я не можу їх знайти в інтерфейсі користувача. У випуску зазначається стан "Якщо реалізовано аромат безпеки Kerberos ...". Я знайшов (але не можу знайти знову) сторінку, яка означає, що вона може бути не на певних моделях. У мене DS211, відповідно до сторінки Інформація про систему. Може, мені не пощастило?

Щоб відображення NFSv4 ID працювало належним чином, і клієнт, і сервер повинні працювати з idmapdдемоном ID Mapper і мати однакове Domainналаштування /etc/idmapd.conf.

Таким чином ваш клієнт NFS надсилає свої ідентифікаційні дані, як roger@example.comу командах NFS на дроті, а ваш ідентифікатор NFS Server відображає їх до користувача, викликаного rogerна сервері NFS. UID та GID не мають значення, вони ідентифікуються в кожній системі.

Однак я не морочуся цим у своїй Synology. Моя спільна папка має такі дозволи:

• Дозволи
  • Місцеві користувачі
    • Адміністратор = читати / писати
• Дозволи NFS
  • Сквош
    • Позначте всіх користувачів для адміністратора

Це призводить до додавання anonuid=1024,anongid=100( adminкористувача та usersгрупи) до експорту в /etc/exportsNAS.

Мій клієнт NFS (у якого не працює Map 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 є надто інженерним і важко продовжувати працювати над перезавантаженнями та автоматикою. Плюс, що за замовчуванням новостворених файлів був 0000, і кожен новий файл створювався в режимі 777, незалежно від того, яким був мій локальний umask.

Моє рішення було подібне до супріямі, але я взяв це трохи далі:

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

$ умаск 
0002
$ cd / mnt / myshare
$ сенсорний тест
$ ls -l тест
-rw-rw-r-- 1 roger roger 0 21 жовтня 18:15 тест

У розділі Synology ви повинні побачити:

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

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