Bonjour la liste, Nous disposons d'une machine sous Centos 7 utilisé en tant que serveur de fichiers et nos clients sont sous Centos 6. Des fois, quand nous tentons d'accéder à un dossier partagé, on se prend des "Permission denied" sans raison apparente. Exemple : [user@client ~]$ mount | grep 'type nfs' server:/ on /nfs type nfs (rw,vers=4,addr=192.168.1.10,clientaddr=192.168.1.51) [user@client~]$ groups docs Users [user@client~]$ls -l /nfs | grep docs drwxrwx---. 21 root docs 4096 Oct 7 10:54 docs [user@client~]$ ls -l /nfs/docs ls: cannot open directory /nfs/docs: Permission denied Configuration du serveur : [root@server ~]# cat /etc/exports /srv/nfs 192.168.1.0/24(ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root) /srv/nfs/docs 192.168.1.0/24(rw,nohide,async,no_subtree_check,no_root_squash,insecure) (...) [root@server ~]# grep -v '^#' /etc/sysconfig/nfs RPCNFSDARGS="" RPCNFSDCOUNT=32 RPCMOUNTDOPTS="-p 892 --manage-gids" STATDARG="" SMNOTIFYARGS="" RPCIDMAPDARGS="" RPCGSSDARGS="" GSS_USE_PROXY="yes" RPCSVCGSSDARGS="" BLKMAPDARGS="" Infos utiles : Le partage réseau est monté à la volé par autofs, l'authentification est gérée par LDAP + SSSD. Auriez-vous des pistes pour corriger ce problème ? Cordialement, Jonathan
Tu as tester en désactivant selinux (setenforce 0) Alexis Le 2 déc. 2015 5:15 PM, "Jonathan Tremesaygues" < jonathan.tremesaygues@menta.fr> a écrit :
Bonjour la liste,
Nous disposons d'une machine sous Centos 7 utilisé en tant que serveur de fichiers et nos clients sont sous Centos 6. Des fois, quand nous tentons d'accéder à un dossier partagé, on se prend des "Permission denied" sans raison apparente.
Exemple : [user@client ~]$ mount | grep 'type nfs' server:/ on /nfs type nfs (rw,vers=4,addr=192.168.1.10,clientaddr=192.168.1.51)
[user@client~]$ groups docs Users
[user@client~]$ls -l /nfs | grep docs drwxrwx---. 21 root docs 4096 Oct 7 10:54 docs
[user@client~]$ ls -l /nfs/docs ls: cannot open directory /nfs/docs: Permission denied
Configuration du serveur : [root@server ~]# cat /etc/exports /srv/nfs
192.168.1.0/24(ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root) /srv/nfs/docs 192.168.1.0/24(rw,nohide,async,no_subtree_check,no_root_squash,insecure) (...)
[root@server ~]# grep -v '^#' /etc/sysconfig/nfs RPCNFSDARGS="" RPCNFSDCOUNT=32 RPCMOUNTDOPTS="-p 892 --manage-gids" STATDARG="" SMNOTIFYARGS="" RPCIDMAPDARGS="" RPCGSSDARGS="" GSS_USE_PROXY="yes" RPCSVCGSSDARGS="" BLKMAPDARGS=""
Infos utiles : Le partage réseau est monté à la volé par autofs, l'authentification est gérée par LDAP + SSSD.
Auriez-vous des pistes pour corriger ce problème ?
Cordialement, Jonathan _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello Une piste à privilégier de suite : Version du serveur nfsd dans le kernel du serveur Centos7 plus récent que la nfs-client-lib des clients en centos6 Erreur classique de débutant en NFS :-) Mets les deux dans une version cohérente et ça fonctionnera mieux. La lib des clients doit forcement être plus récente que le kernel pour que ça tombe en marche de façon satisfaisante Cdlt A Le 2 décembre 2015 17:28, Alexis Lameire <alexis.lameire@gmail.com> a écrit :
Tu as tester en désactivant selinux (setenforce 0)
Alexis Le 2 déc. 2015 5:15 PM, "Jonathan Tremesaygues" < jonathan.tremesaygues@menta.fr> a écrit :
Bonjour la liste,
Nous disposons d'une machine sous Centos 7 utilisé en tant que serveur de fichiers et nos clients sont sous Centos 6. Des fois, quand nous tentons d'accéder à un dossier partagé, on se prend des "Permission denied" sans raison apparente.
Exemple : [user@client ~]$ mount | grep 'type nfs' server:/ on /nfs type nfs (rw,vers=4,addr=192.168.1.10,clientaddr=192.168.1.51)
[user@client~]$ groups docs Users
[user@client~]$ls -l /nfs | grep docs drwxrwx---. 21 root docs 4096 Oct 7 10:54 docs
[user@client~]$ ls -l /nfs/docs ls: cannot open directory /nfs/docs: Permission denied
Configuration du serveur : [root@server ~]# cat /etc/exports /srv/nfs
192.168.1.0/24(ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root) /srv/nfs/docs <http://192.168.1.0/24(ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root)/srv/nfs/docs> 192.168.1.0/24(rw,nohide,async,no_subtree_check,no_root_squash,insecure) (...)
[root@server ~]# grep -v '^#' /etc/sysconfig/nfs RPCNFSDARGS="" RPCNFSDCOUNT=32 RPCMOUNTDOPTS="-p 892 --manage-gids" STATDARG="" SMNOTIFYARGS="" RPCIDMAPDARGS="" RPCGSSDARGS="" GSS_USE_PROXY="yes" RPCSVCGSSDARGS="" BLKMAPDARGS=""
Infos utiles : Le partage réseau est monté à la volé par autofs, l'authentification est gérée par LDAP + SSSD.
Auriez-vous des pistes pour corriger ce problème ?
Cordialement, Jonathan _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Alexandre
Ça m'a l'air d'être une bonne piste. Malheureusement, pas le temps de faire une migration du SI pour le moment. Donc si c'est bien ça, on va continuer à vivre avec encore un peu :-) Jonathan On 12/02/2015 06:00 PM, Alexandre Legrix wrote:
Hello
Une piste à privilégier de suite :
Version du serveur nfsd dans le kernel du serveur Centos7 plus récent que la nfs-client-lib des clients en centos6 Erreur classique de débutant en NFS :-)
Mets les deux dans une version cohérente et ça fonctionnera mieux. La lib des clients doit forcement être plus récente que le kernel pour que ça tombe en marche de façon satisfaisante
Cdlt A
Le 2 décembre 2015 17:28, Alexis Lameire <alexis.lameire@gmail.com <mailto:alexis.lameire@gmail.com>> a écrit :
Tu as tester en désactivant selinux (setenforce 0)
Alexis
Le 2 déc. 2015 5:15 PM, "Jonathan Tremesaygues" <jonathan.tremesaygues@menta.fr <mailto:jonathan.tremesaygues@menta.fr>> a écrit :
Bonjour la liste,
Nous disposons d'une machine sous Centos 7 utilisé en tant que serveur de fichiers et nos clients sont sous Centos 6. Des fois, quand nous tentons d'accéder à un dossier partagé, on se prend des "Permission denied" sans raison apparente.
Exemple : [user@client ~]$ mount | grep 'type nfs' server:/ on /nfs type nfs (rw,vers=4,addr=192.168.1.10,clientaddr=192.168.1.51)
[user@client~]$ groups docs Users
[user@client~]$ls -l /nfs | grep docs drwxrwx---. 21 root docs 4096 Oct 7 10:54 docs
[user@client~]$ ls -l /nfs/docs ls: cannot open directory /nfs/docs: Permission denied
Configuration du serveur : [root@server ~]# cat /etc/exports /srv/nfs 192.168.1.0/24(ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root) /srv/nfs/docs <http://192.168.1.0/24%28ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root%29/srv/nfs/docs> 192.168.1.0/24(rw,nohide,async,no_subtree_check,no_root_squash,insecure) <http://192.168.1.0/24%28rw,nohide,async,no_subtree_check,no_root_squash,insecure%29> (...)
[root@server ~]# grep -v '^#' /etc/sysconfig/nfs RPCNFSDARGS="" RPCNFSDCOUNT=32 RPCMOUNTDOPTS="-p 892 --manage-gids" STATDARG="" SMNOTIFYARGS="" RPCIDMAPDARGS="" RPCGSSDARGS="" GSS_USE_PROXY="yes" RPCSVCGSSDARGS="" BLKMAPDARGS=""
Infos utiles : Le partage réseau est monté à la volé par autofs, l'authentification est gérée par LDAP + SSSD.
Auriez-vous des pistes pour corriger ce problème ?
Cordialement, Jonathan _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Alexandre
Il n'y a pas d'alertes dans /var/log/audit/* qui laisse supposer que ça soit SELinux qui pose problème. De plus, je pense que si SELinux était le coupable, le problème serait systématique et non ponctuel comme là (on doit le rencontrer deux fois par mois maximum et un reboot de la machine cliente concernée suffit à le contourner). Jonathan On 12/02/2015 05:28 PM, Alexis Lameire wrote:
Tu as tester en désactivant selinux (setenforce 0)
Alexis
Le 2 déc. 2015 5:15 PM, "Jonathan Tremesaygues" <jonathan.tremesaygues@menta.fr <mailto:jonathan.tremesaygues@menta.fr>> a écrit :
Bonjour la liste,
Nous disposons d'une machine sous Centos 7 utilisé en tant que serveur de fichiers et nos clients sont sous Centos 6. Des fois, quand nous tentons d'accéder à un dossier partagé, on se prend des "Permission denied" sans raison apparente.
Exemple : [user@client ~]$ mount | grep 'type nfs' server:/ on /nfs type nfs (rw,vers=4,addr=192.168.1.10,clientaddr=192.168.1.51)
[user@client~]$ groups docs Users
[user@client~]$ls -l /nfs | grep docs drwxrwx---. 21 root docs 4096 Oct 7 10:54 docs
[user@client~]$ ls -l /nfs/docs ls: cannot open directory /nfs/docs: Permission denied
Configuration du serveur : [root@server ~]# cat /etc/exports /srv/nfs 192.168.1.0/24(ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root) /srv/nfs/docs <http://192.168.1.0/24%28ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root%29%0A/srv/nfs/docs> 192.168.1.0/24(rw,nohide,async,no_subtree_check,no_root_squash,insecure) <http://192.168.1.0/24%28rw,nohide,async,no_subtree_check,no_root_squash,insecure%29> (...)
[root@server ~]# grep -v '^#' /etc/sysconfig/nfs RPCNFSDARGS="" RPCNFSDCOUNT=32 RPCMOUNTDOPTS="-p 892 --manage-gids" STATDARG="" SMNOTIFYARGS="" RPCIDMAPDARGS="" RPCGSSDARGS="" GSS_USE_PROXY="yes" RPCSVCGSSDARGS="" BLKMAPDARGS=""
Infos utiles : Le partage réseau est monté à la volé par autofs, l'authentification est gérée par LDAP + SSSD.
Auriez-vous des pistes pour corriger ce problème ?
Cordialement, Jonathan _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour à tous, Même problème entre un Xubuntu comme client, et un FreeBSD 10.2 côté serveur partageant un tank ZFS... "On s'autorise à penser dans les milieux autorisés qu'un bug existerait dans les versions récentes du NFS client sous plusieurs distros Linux ....." SI quelqu'un a trouvé le pourquoi du comment (passage en unstable, ou autre), je suis également preneur... Excellente journée, ----- Mail original ----- De: "Jonathan Tremesaygues" <jonathan.tremesaygues@menta.fr> À: "Alexis Lameire" <alexis.lameire@gmail.com> Cc: "French SysAdmin Group" <frsag@frsag.org> Envoyé: Jeudi 3 Décembre 2015 09:24:53 Objet: Re: [FRsAG] NFS - Permission denied sans raison apparente Il n'y a pas d'alertes dans /var/log/audit/* qui laisse supposer que ça soit SELinux qui pose problème. De plus, je pense que si SELinux était le coupable, le problème serait systématique et non ponctuel comme là (on doit le rencontrer deux fois par mois maximum et un reboot de la machine cliente concernée suffit à le contourner). Jonathan On 12/02/2015 05:28 PM, Alexis Lameire wrote: Tu as tester en désactivant selinux (setenforce 0) Alexis Le 2 déc. 2015 5:15 PM, "Jonathan Tremesaygues" < jonathan.tremesaygues@menta.fr > a écrit : Bonjour la liste, Nous disposons d'une machine sous Centos 7 utilisé en tant que serveur de fichiers et nos clients sont sous Centos 6. Des fois, quand nous tentons d'accéder à un dossier partagé, on se prend des "Permission denied" sans raison apparente. Exemple : [user@client ~]$ mount | grep 'type nfs' server:/ on /nfs type nfs (rw,vers=4,addr=192.168.1.10,clientaddr=192.168.1.51) [user@client~]$ groups docs Users [user@client~]$ls -l /nfs | grep docs drwxrwx---. 21 root docs 4096 Oct 7 10:54 docs [user@client~]$ ls -l /nfs/docs ls: cannot open directory /nfs/docs: Permission denied Configuration du serveur : [root@server ~]# cat /etc/exports /srv/nfs 192.168.1.0/24(ro,nohide,async,no_subtree_check,no_root_squash,insecure,fsid=root) /srv/nfs/docs 192.168.1.0/24(rw,nohide,async,no_subtree_check,no_root_squash,insecure) (...) [root@server ~]# grep -v '^#' /etc/sysconfig/nfs RPCNFSDARGS="" RPCNFSDCOUNT=32 RPCMOUNTDOPTS="-p 892 --manage-gids" STATDARG="" SMNOTIFYARGS="" RPCIDMAPDARGS="" RPCGSSDARGS="" GSS_USE_PROXY="yes" RPCSVCGSSDARGS="" BLKMAPDARGS="" Infos utiles : Le partage réseau est monté à la volé par autofs, l'authentification est gérée par LDAP + SSSD. Auriez-vous des pistes pour corriger ce problème ? Cordialement, Jonathan _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Hello,
Bonjour à tous, Même problème entre un Xubuntu comme client, et un FreeBSD 10.2 côté serveur partageant un tank ZFS... "On s'autorise à penser dans les milieux autorisés qu'un bug existerait dans les versions récentes du NFS client sous plusieurs distros Linux ....."
SI quelqu'un a trouvé le pourquoi du comment (passage en unstable, ou autre), je suis également preneur...
une piste a explorer car depuis quelques temps Linux a des certaines tendances a sortir des bugs sur NFS qui avaient été réglés avant (tests de non regression... bref #joker). La piste dont je pense est de voir si les UID/GID des users qui ont ces problèmes n'ont pas plus que 14 groupes, exemple : $ id uid=1000(kiwi) gid=1000(kiwi) groups=1000(kiwi),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),110(lpadmin),113(scanner),118(bluetooth) Là j'ai 12 groupes... suffit de peu pour passer la limite de 14... Pourquoi 14, c'est une "feature" de nfsv3 qui "normalement" est bypassé par nfsv4 avec ldap + kerberos... Mais vu les bugs de 2000 que j'ai vu sur les kernel 3.2 réapparaitre je ne serais pas étonné de voir ça revenir.... My 0,02€ Xavier
Hello. La piste de Xavier semble plus probante effectivement pour un soucis intermittent. Le 3 décembre 2015 13:46, Erik LE VACON <erik@levacon.net> a écrit :
La piste dont je pense est de voir si les UID/GID des users qui ont ces problèmes n'ont pas plus que 14 groupes,
Merci Xavier, "much apprécié" :) Je vais tester avec un user lambda monogroupe, juste pour voir, et confirme le point. _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
-- Alexandre
Remarque pertinente, nos utilisateurs ont tendance à appartenir à pas mal de groupes (41 pour ma part) et on n'utilise pas Kerberos. Mais je pensais que le paramètre '--manage-gids' de rpc.mountd servait justement à contourner ce problème. Et de toute façon le dernier utilisateur auquel s'est arrivé n'appartenait qu'à 12 groupes :-/ Jonathan On 12/03/2015 02:57 PM, Alexandre Legrix wrote:
La piste de Xavier semble plus probante effectivement pour un soucis intermittent.
participants (5)
-
Alexandre Legrix -
Alexis Lameire -
Erik LE VACON -
Jonathan Tremesaygues -
Xavier Beaudouin