4 203
modifications
« Nfs » : différence entre les versions
Aller à la navigation
Aller à la recherche
→Overview des permissions NFS
| (9 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 2 : | Ligne 2 : | ||
[[Category:debian]] | [[Category:debian]] | ||
[[Category:networking]] | [[Category:networking]] | ||
[[ | [[Category:desktop]] | ||
=Installation classique= | =Installation classique= | ||
| Ligne 11 : | Ligne 11 : | ||
Pour créer un partage, éditez le fichier <code>/etc/exports</code> : | Pour créer un partage, éditez le fichier <code>/etc/exports</code> : | ||
<pre>/home/pfoo/data/ 192.168.10.0/255.255.255.0(ro | <pre>/home/pfoo/data/ 192.168.10.0/255.255.255.0(ro,sync,no_subtree_check)</pre> | ||
Note : Si l'un de vos clients | Note : Si l'un de vos clients doit pouvoir monter le partage nfs sans être root sur sa machine il faudra ajouter l'option <code>insecure</code> sur la ligne de l'exports. | ||
Pour permettre la lecture et l'écriture, remplacez <code>ro</code> par <code>rw</code> | Pour permettre la lecture et l'écriture, remplacez <code>ro</code> par <code>rw</code><br> | ||
<code>192.168.10.0/255.255.255.0</code> signifie que le partage sera accessible pour les ips <code>192.168.10.X</code> | <code>192.168.10.0/255.255.255.0</code> signifie que le partage sera accessible pour les ips <code>192.168.10.X</code> | ||
| Ligne 64 : | Ligne 64 : | ||
<pre>STATDOPTS="--port 2231"</pre> | <pre>STATDOPTS="--port 2231"</pre> | ||
Modifiez la ligne suivante dans <code | Modifiez la ligne suivante dans <code>/etc/default/nfs-kernel-server</code> : | ||
<pre>RPCMOUNTDOPTS="--port 2233"</pre> | <pre>RPCMOUNTDOPTS="--port 2233"</pre> | ||
| Ligne 117 : | Ligne 117 : | ||
</pre> | </pre> | ||
Il faudra que l'utilisateur qui doit accéder à la ressource NFS côté client ait lui aussi l'uid 1000 et le gid 1000 (dans une moindre mesure) et ce tout simplement pour respecter les permissions linux (jusque là c'est logique, non ?). Mais Dans le cas présent, même l'utilisateur root sur le client n'aura pas les droits sur le dossier ! Bizarre ? non, c'est lié à la directive root_squash qui, en gros, remap les accès fait par l'utilisateur root sur le client vers l'uid/gid squash (numéro 65534 si ça vous intéresse).<br> | Il faudra que l'utilisateur qui doit accéder à la ressource NFS côté client ait lui aussi l'uid 1000 et le gid 1000 (dans une moindre mesure) et ce tout simplement pour respecter les permissions linux (jusque là c'est logique, non ?). Mais Dans le cas présent, même l'utilisateur root sur le client n'aura pas les droits sur le dossier ! Bizarre ? non, c'est lié à la directive root_squash qui, en gros, remap les accès fait par l'utilisateur root sur le client vers l'uid/gid squash (numéro 65534 si ça vous intéresse).<br> | ||
Et pour qu'un autre utilisateur ait des droits, il suffit de suivre les permissions linux classiques. | Et pour qu'un autre utilisateur ait des droits, il suffit de suivre les permissions linux classiques. Mais attention, encore une fois, c'est sur le serveur qu'elles comptent. Si vous avez, sur le client nfs, un utilisateur d'uid 1001, membre du groupe de gid 1000 ... ça ne marchera pas, il faut aussi que l'utilisateur d'uid 1001 soit membre du groupe de gid 1000 sur le serveur nfs. | ||
Si nous modifions la ligne comme suit : | Si nous modifions la ligne comme suit : | ||
| Ligne 126 : | Ligne 126 : | ||
* all_squash et root_squash : force l'attribution de l'uid/gid squash aux clients | * all_squash et root_squash : force l'attribution de l'uid/gid squash aux clients | ||
* no_all_squash et no_root_squash : conserve l'uid/gid original des clients | * no_all_squash et no_root_squash : conserve l'uid/gid original des clients | ||
* par défaut, si rien n'est précisé : root_squash et no_all_squash. | |||
Alors, pourquoi tout ce bordel puisqu'au final il faut quand même que les userid correspondent ? C'est la qu'interviennent les directives <code>anonuid</code> et <code>anongid</code>. | Alors, pourquoi tout ce bordel puisqu'au final il faut quand même que les userid correspondent ? C'est la qu'interviennent les directives <code>anonuid</code> et <code>anongid</code>. | ||
| Ligne 131 : | Ligne 132 : | ||
<pre>/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,all_squash,anonuid=1000,anongid=1000)</pre> | <pre>/data 192.168.1.0/255.255.255.0(rw,sync,root_squash,all_squash,anonuid=1000,anongid=1000)</pre> | ||
Tous les utilisateurs (car all_squash) et l'utilisateur root (car root_squash) se retrouvent mappé vers l'uid squash, a savoir, l'uid 1000. Résultat, tous les utilisateurs (et root) auront les droits sur les fichiers de /data au travers de nfs. | Tous les utilisateurs (car all_squash) et l'utilisateur root (car root_squash) se retrouvent mappé vers l'uid squash, a savoir, l'uid 1000. Résultat, tous les utilisateurs (et root) auront les droits sur les fichiers de /data au travers de nfs. | ||
=NFS4= | |||