Comment puis-je obtenir un accès en lecture / écriture au partage NFS du Synology NAS?

Je n'ai accès en lecture qu'au partage NFS monté.

Avec 'no squash mapping' défini sur le NAS, l'utilisateur régulier d'Ubuntu obtient Permission denieden essayant d' cdaccéder au partage et ne peut obtenir un accès en lecture qu'en utilisant sudo.
En utilisant le paramètre squash `` mapper tous les utilisateurs à l'administrateur '', l'utilisateur régulier du client peut cdaccéder au partage et n'y a qu'un accès en lecture. L'utilisation sudon'autorise pas l'écriture.

Synology NAS:
DS214> id username
uid=1026(username) gid=100(users) groups=100(users),101(administration)

pas de squash (pas de mapping)
DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,no_root_squash,insecure_locks,sec=sys,anonuid=1025,anongid=100)

tout squash (mapper tous les utilisateurs à l'administrateur)
DS214> cat /etc/exports
/volume1/Files 10.1.1.2(rw,async,no_wdelay,all_squash,insecure_locks,sec=sys,anonuid=1024,anongid=100)

Client Ubuntu:
$ cat /etc/fstab
10.1.1.214:/volume1/Files /mnt/nfs/Files nfs rw,user,auto 0 0

$ id username
uid=1000 gid=1000(username) groups=1000(username), <etc>

$ ls -n /mnt/nfs
drwxrwxrwx 9 0 0 4096 Sep 25 01:28 Files

$ ls -n /mnt/nfs/Files
drwxr-xr-x 11 1026 100 4096 Sep 24 22:05 Data

(J'ai initialement signalé par erreur qu'en utilisant l' sudoaccès en écriture activé) Je peux ouvrir un fichier dans le partage NFS monté avec sudo vi /mnt/nfs/Files/Data/test.filemais je ne peux pas écrire les modifications dans le fichier même avec sudo. Le message d'erreur vi lors de la :w!commande est:
"test.file" E212: Can't open file for writing

— marsilea
source

NFS vérifie les autorisations d'accès par rapport aux ID utilisateur (UID). L'UID de l'utilisateur sur votre machine locale doit correspondre à l'UID du propriétaire des fichiers auxquels vous essayez d'accéder sur le serveur . Accédez au serveur et examinez les autorisations de fichier. À quel UID (savoir avec id username) appartiennent-ils et quelles autorisations sont définies?

— Nephente

Pouvez-vous même cdaccéder à la monture en tant qu'utilisateur régulier? Si oui, je suggère ce qui suit. Pour confirmer ou réfuter mes soupçons, procédez comme suit: Sur le client cddans le montage et faites ls -n. Cela répertoriera les propriétaires de fichiers et les groupes avec leurs ID respectifs. Vous devrez le faire avec, sudoje suppose. Ajoutez une ligne ou deux de la sortie à votre question, ainsi que la sortie de id (non sudo!) Si vous ne pouvez même cdpas monter sur le montage en tant qu'utilisateur normal, vous devrez vérifier les autorisations du répertoire sur lequel vous exportez. le serveur.

— Nephente

Je ne pouvais pas cdentrer dans la monture en tant qu'utilisateur régulier. L'utilisation de Squash sur le serveur pour forcer les autorisations fonctionne comme un correctif temporaire pour accorder des autorisations. Enquête sur les autorisations du serveur et id username.

— marsilea

Merci, je pense qu'il serait préférable d'utiliser nfs de la bonne manière plutôt que de simplement utiliser la force brute avec Squash: 'Mapper tous les utilisateurs à admin' sur le serveur ..

— marsilea

Ça dépend. Faites-vous confiance aux clients et aux utilisateurs? Si vous ne le faites pas, NFSv3 n'est pas approprié après tout, car toute personne ayant un accès root à un client peut usurper des UID. Si vous avez besoin d'une authentification appropriée, vous feriez mieux d'utiliser SMB. L'authentification avec NFSv4 nécessite l'exécution d'un Kerberos qui est plutôt compliqué. Mais néanmoins, votre sortie me déroute ... Je suppose que le point de montage est /mnt/nfs/Files. Bien Filesqu'appartenant à root, la permission permet à quiconque de faire quoi que ce soit. Cela n'a aucun sens pour moi pourquoi vous auriez du mal à entrer ce répertoire en tant qu'utilisateur. Peut-être publier la ligne pertinente de /etc/exports?

— Nephente

Réponses:

NFSv2 / 3 gère les autorisations uniquement en fonction de l'UID et du GID. Les autorisations de fichiers sur le serveur sont comparées aux identifiants des utilisateurs et des groupes sur le client. C'est pourquoi NFSv <4 est, par conception, non sécurisé dans les environnements où les utilisateurs ont un accès root aux machines clientes; L'usurpation d'identité UID est triviale dans ce cas.

Notez que NFSv4 offre une authentification client et utilisateur via Kerberos5. Si une authentification avec nom d'utilisateur et mot de passe est nécessaire, il est souvent bien plus facile de recourir à Samba (SMB / CIFS) au lieu de configurer un Kerberos, même dans des environnements Linux purs.

Au moins empêcher l' escalade des privilèges root, les partages NFS sont exportés par défaut avec l'option root_squash, qui tracera toutes les demandes des clients venant de root (uid=0, gid=0)la anonuidet anongid. Ce comportement peut être remplacé par no_root_squash, accordant un accès root à l'exportation.

Ici, nous voyons un autre inconvénient. Pour fonctionner correctement, NFS exige essentiellement que vous ayez le même UID / GID sur toutes les machines. Les fichiers auxquels vous souhaitez accéder appartiennent 1026et ont les autorisations 755. Vous êtes utilisateur sur le client uid=1000. Les GID ne correspondent pas non plus, vous obtenez donc uniquement les autorisations mondiales. Par conséquent, aucun accès en écriture.

Pour résoudre ce problème, vous pouvez effectuer plusieurs opérations:

Sur le NAS, changez le propriétaire des fichiers en 1000. Vous auriez peut-être besoin de créer ce compte particulier. Comment cela affectera d'autres services, je ne peux pas dire.
Remplacez l'UID de votre utilisateur local par 1026.
Étant donné que vous êtes le seul à accéder aux fichiers sur le serveur, vous pouvez faire croire au serveur que toutes les demandes proviennent de l'UID approprié. Pour cela, NFS a l'option all_squash. Il indique au serveur de mapper toutes les demandes à l'utilisateur anonyme, spécifié par anonuid,anongid.

Ajoutez les options all_squash,anonuid=1026,anongid=100à l'exportation dans /etc/exports.

Soyez prudent cependant, car cela rendra quiconque monte l'exportation efficacement le propriétaire de ces fichiers!

Si vous partagez votre réseau avec des personnes et leurs clients en qui vous ne faites pas entièrement confiance pour ne pas faire de mal à vos fichiers, vous devriez vraiment chercher une méthode de partage de fichiers qui offre une authentification. À mon avis, Samba est le moyen le plus simple d'y parvenir.

— Nephente
source

J'ai choisi NFS parce que je pensais que cela pourrait avoir des avantages pour Linux vers Linux, car j'aimerais pouvoir sauvegarder le NAS par rsync sur un lecteur USB externe sur le client Ubuntu (le système DSM de Synology n'offre pas de synchronisation sur un lecteur USB) , tout en conservant la propriété du fichier et les informations d'autorisation. Une réponse complète et merci pour les conseils.

— marsilea

Faites showmount -e 10.1.1.214pour voir les options d'exportation. Permission deniedl'erreur provient du serveur NFS lui-même. Essayez de changer l'option de rw,user,autoà defaults.

— Muhammad Aizuddin
source