Mappage des ID utilisateur avec NFS sur Synology NAS

J'ai une boîte Synology NAS (exécutant DSM 5.1), et j'ai exporté un répertoire via NFS. J'essaie de le monter sur ma boîte Ubuntu.

Cela fonctionne généralement bien, mais j'ai des problèmes avec les mappages d'utilisateurs et de groupes. Sur la boîte Ubuntu, je suis uid 1000 (roger), gid 1000 (roger). Sur le Synology, j'ai uid 1026 (roger), groupe 100 (utilisateurs).

Si j'utilise NFSv3, il utilise des valeurs numériques uid / gid, ce qui signifie que la propriété est gâchée sur le Synology.

Si je devais seulement accéder au montage NFS à partir de la même boîte Ubuntu, en utilisant le même utilisateur, ce serait bien, mais j'accède également au répertoire à partir d'une boîte Windows, en utilisant CIFS (SMB), ce qui signifie que les autorisations sont faux.

Si j'utilise NFSv4 ( mount -o nfsvers=4), avec les paramètres par défaut sur le Synology, les fichiers détenus par roger.usersle Synology semblent appartenir à roger.userslorsqu'ils sont visualisés à partir de la boîte Ubuntu. C'est bon.

Cependant, quand j'ai touchun fichier:

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

Il finit par appartenir 1000.1000à Synology et s'affiche comme appartenant à nobody.4294967294lorsqu'il est vu depuis la boîte Ubuntu.

Tout ce que je peux trouver sur le sujet sur les forums Synology est daté de 2011, lorsque NFSv4 n'était pas pris en charge, ou consiste en des personnes posant la même question et abandonnant.

Pour être complet, /etc/exportsa:

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

... et je le monte sur la box Ubuntu avec:

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

J'ai trouvé quelques indices que cela sec=syspourrait être un problème: pourquoi le mappage uid / gid NFSv4 ne fonctionne pas avec AUTH_UNIX (AUTH_SYS) , mais cela n'a pas de solution.

Existe-t-il un moyen simple de contourner ce problème? Y at - il un plus complexe ( la toux Kerberos toux ) façon de résoudre ce problème?

Sérieusement, si Kerberos est la réponse, je prendrai ce coup, mais j'aimerais savoir avant de perdre beaucoup de temps dessus.

Mise à jour : bien que la documentation de Synology parle de diverses options Kerberos, je ne les trouve pas dans l'interface utilisateur. Les notes de version indiquent "Si la version de sécurité Kerberos est implémentée ...". J'ai trouvé (mais ne peux pas retrouver) une page qui implique qu'elle pourrait ne pas être sur certains modèles. J'ai un DS211, selon la page Informations système. Peut-être que je n'ai pas de chance?

Pour que le mappage d'ID NFSv4 fonctionne correctement, le client et le serveur doivent exécuter le idmapddémon ID Mapper et avoir le même Domainconfiguré dans /etc/idmapd.conf.

De cette façon, votre client NFS envoie ses informations d'identification comme [email protected]dans les commandes NFS sur le câble, et votre idmapper de serveur NFS mappe cela à un utilisateur appelé rogersur le serveur NFS. L'UID et le GID n'ont pas d'importance, ils sont mappés sur chaque système par l'idmapper.

Cependant, je ne me préoccupe pas de cela sur ma Synology. Mon dossier partagé dispose des autorisations suivantes:

• Autorisations
  • Utilisateurs locaux
    • Admin = lecture / écriture
• Autorisations NFS
  • Écraser
    • Mapper tous les utilisateurs à l'administrateur

Il en résulte que anonuid=1024,anongid=100(l' adminutilisateur et le usersgroupe) sont ajoutés à l'exportation /etc/exportssur le NAS.

Mon client NFS (qui n'a pas le mappeur d'ID en cours d'exécution) envoie mes commandes NFS en tant qu'utilisateur ( 1000:1000) et comme cet UID et GID n'existent pas sur le NAS, il traduit mon UID et GID en 1024:100donc je suis traité comme le Utilisateur administrateur disposant des autorisations complètes.

C'est une utilisation terriblement non professionnelle et non sécurisée de NFS pour un environnement professionnel, mais juste pour moi d'accéder à mes fichiers à la maison, c'est un abus de comportement NFS qui est acceptable pour moi.

Une autre option consiste à faire en sorte que rogerUID et GID soient identiques sur le client NFS et le NAS, vous pouvez alors utiliser NFSv4 sans mappage d'ID, ou vous pouvez alors utiliser NFSv3 qui ne repose que sur UID et GID.

J'ai vraiment eu du mal avec le même problème. J'ai vécu l'énorme peine de configurer un serveur Kerberos avec Docker sur le Synology, de configurer le mappage d'ID et je n'aimais toujours pas le comportement. Kerberos est beaucoup trop sur-conçu et difficile de continuer à travailler sur les redémarrages et le montage automatique. De plus, le umask par défaut des fichiers nouvellement créés était 0000, et chaque nouveau fichier a été créé en mode 777, quel que soit mon umask local.

Ma solution était similaire à celle de suprjami, mais je l'ai poussée un peu plus loin:

• Créez un nouvel utilisateur avec l'interface Web Synology, nommez-le quelque chose comme roger.remote. Faites de même pour un groupe d'utilisateurs et nommez-le de la même manière que le nom d'utilisateur.
• Sur le Synology en tant que root, modifiez / etc / passwd et changez roger.remotel'UID de 1000 et le GID de 1000
• éditez / etc / group et changez également le groupe roger.remoteen 1000
• Dans l'interface utilisateur Web de Synology, définissez squash sur "tous les utilisateurs à administrer" et enregistrez
• En tant que root, modifiez / etc / exports et changez l'UID / GID en anonuid=1000,anongid=1000
• Redémarrez NFS avec /usr/syno/etc.defaults/rc.sysv/S83nfsd.sh restart
• C'est aussi un peu hacky - mais chmod 777 /volume1. J'ai eu beaucoup de problèmes étranges avec mon répertoire personnel monté. KDE ne démarrerait pas car la access()fonction glibc retournerait un accès refusé sur le répertoire NFS monté. (Mais tous les sous-répertoires fonctionneraient) Firefox avait également un problème similaire, où il refusait d'enregistrer des fichiers dans le répertoire monté en raison de la vérification d'accès. Même si les autorisations étaient correctes, je pouvais toucher / créer / écrire des fichiers dans le répertoire monté. La modification du répertoire parent / volume1 en écriture universelle a corrigé ce problème stupide et a trompé les applications clientes pour y écrire.
• Supprimez toutes les ACL du système de fichiers du partage. Grâce à de nombreuses expérimentations aléatoires, j'ai trouvé que ces listes de contrôle d'accès provoquaient des problèmes avec le masque de mode des fichiers créés. Je ne suis pas un maître ACL, donc il y a peut-être une solution plus élégante. En tant que root sur le Synology, faites synoacltool -del /volume1/myshare. Vous devriez voir le +symbole supprimé de la sortie ls -l.
• Changez la propriété du partage pour votre nouvel utilisateur: chown roger.remote:roger.remote /volume1/myshare
• Changez le mode en 755: chmod 755 /volume1/myshare
• Montez le volume sur le client, testez les permissions, ça devrait marcher! Assurez-vous de toucher également un fichier et vérifiez que votre umash bash est correctement appliqué.

$ umask 
0002
$ cd / mnt / myshare
$ touch test
$ ls -l test
-rw-rw-r-- 1 roger roger 0 octobre 21 18:15 test

Sur la Synology, vous devriez voir:

# ls -l / volume1 / myshare / test
-rw-rw-r-- 1 roger.remote roger.remote 0 oct 21 18:15 test

Prendre plaisir!