[resolu]Montage nfs lecture ecriture

Bonjour,

je voudrais faire un montage nfs, j’ai donc écrit ces lignes

# cat /etc/exports
## Montage nfs locaux
/mnt/nfsServ    127.0.0.1(sync,rw,no_subtree_check) 
/etc/kde-profile  127.0.0.1(sync,rw,no_subtree_check) 

Puis je tape :

# mkdir /tmp/nfs
# mount psikharpax:/etc/kde-profile/ /tmp/nfs  

Mais je n’arrivce pas a y accéder en écriture, en root comme en utilisateur simple.

Que faire :question: Est ce possible ? :smt013

surement, j’ai pas trop lu, mais ce n’est pas l’endroit pour poser la question.
Je bascule dans la section “support” qui sert au … support !
Merci de faire attention ou tu postes.

Ok, si tu le dis …
Mais moi je viens de trouver la réponse :
pour que tout le root puisse écrire, il faut spécifier :


/etc/kde-profile  127.0.0.1(sync,rw,no_subtree_check,no_root_squash) 

Quelle est l’intérêt d’autoriser uniquement l’interface de loopback à accéder à ton partage NFS.?

L’intérêt pratique : aucun :slightly_smiling:
C’est juste pour le test, avant un déploiement sur un réseau, je suis obligé de tester en local (pas envie de planter 80 machines, elles ont déjà d’autres partages nfs qui n’ont pas été faits par moi)

Juste par curiosité. Pour un déploiement sur 80 machine ne faudrait t-il pas forcer l’uid et le gid de tes clients pour les différentes opérations sur le partage NFS.

Ou bien mettre en place Kerberos ?

Pour ca il va me falloir être un petit peu plus précis :
Debian va être deployé sur un réseau de 80 machinbes ouvertes au public.
pour éviter des conneries de la part des utilisateurs finaux (médiathèque, points cyb) je dois utiliser Kiosk, qui permet de réduire les droits des utilisateurs.

Kiosk fonctionne avec un système de profils, contenus dans

Pour des question de gestion des profils, je souhiaite monter un des profils en nfs, de sortent que toutes les machines accèdent au même.

Est ce plus clair ?

La seule contrainte d’écriture, c’est que le root local puisse accéder au fichiers de conf, d’ou le

no_root_squash

Oui, tu fais confiance aux clients. Le problème vient du fait que root a besoin d’un accès avec plus de privièges. Je ne penses pas que les options no_root_squash et all_squash peuvent se combiner car cela me semble un peu contradictoire, mais autrement cela aurait été une bonne solution.

Oui, certes,mais les clients ne se connecteront jamais en root, sauf un administrateur en cas d’urgence, d’ou le no_root_squash.
De plus cette zone n’est pas accessible ne lecture / ecriture pour les clients single user.