Question mount.nfs: accès refusé par le serveur lors du montage (authentification Kerberos)


Il y a beaucoup de références à cette erreur sur Goggle, et même une question ici avec le même titre, mais il semble que "l'accès refusé par le serveur lors du montage" est une erreur fourre-tout. J'ai essayé des suggestions que d'autres ont utilisées pour résoudre ce problème, mais elles n'ont pas fonctionné dans mon cas.

J'essaie de configurer un serveur de fichiers NFS basé sur Kerberos avec des logements partagés pour un réseau Linux. J'utilise les serveurs et les clients Ubuntu 11.04.

Lorsque vous essayez de monter un partage en utilisant:

mount 192.168.1.115:/export/home/ /media/tmp

Je reçois:

mount.nfs: access denied by server while mounting 192.168.1.115:/export/home/

C’est la même chose si je le monte à partir d’une machine cliente ou du serveur lui-même.

Sur le serveur, dans /var/log/syslog Je reçois:

Aug 25 06:22:37 nfs mountd[1580]: authenticated mount request from
       192.168.1.115:835 for /export/home (/export/home)    

Aug 25 06:22:37 nfs mountd[1580]: authenticated unmount request from
       192.168.1.115:766 for /export/home (/export/home)

Ce qui est étrange, car il dit que la demande est authentifiée et non refusée.

/ etc / exports:

/export *(rw,fsid=0,crossmnt,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5)
/export/home    *(rw,insecure,async,no_subtree_check,sec=krb5p:krb5i:krb5)


Sur le client:

me@dt1:/$ rpcinfo -p 192.168.1.115

   program vers proto   port
    100000    2   tcp    111  portmapper
    100024    1   udp  37320  status
    100024    1   tcp  48460  status
    100003    2   tcp   2049  nfs
    100003    3   tcp   2049  nfs
    100003    4   tcp   2049  nfs
    100227    2   tcp   2049
    100227    3   tcp   2049
    100003    2   udp   2049  nfs
    100003    3   udp   2049  nfs
    100003    4   udp   2049  nfs
    100227    2   udp   2049
    100227    3   udp   2049
    100021    1   udp  58625  nlockmgr
    100021    3   udp  58625  nlockmgr
    100021    4   udp  58625  nlockmgr
    100021    1   tcp  49616  nlockmgr
    100021    3   tcp  49616  nlockmgr
    100021    4   tcp  49616  nlockmgr
    100005    1   udp  45627  mountd
    100005    1   tcp  60265  mountd
    100005    2   udp  45627  mountd
    100005    2   tcp  60265  mountd
    100005    3   udp  45627  mountd
    100005    3   tcp  60265  mountd

Des suggestions que je pourrais essayer?


5
2017-08-25 06:58


origine


Y a-t-il une entrée dans /etc/hosts.deny sur le serveur? - quanta
Tout est commenté dans /etc/hosts.deny et /etc/hosts.allow - Nick
Qu'est-ce que rpcinfo -p 192.168.1.115 dire quand on court du client? - quanta
J'ai ajouté la sortie ci-dessus. - Nick
Peut-être un bug: bugs.debian.org/cgi-bin/bugreport.cgi?bug=515754 - quanta


Réponses:


Peut-être que cela aidera:

Il m'est également arrivé de ne pas insérer correctement le chemin de partage.

# mount 192.168.2.101:/share /local/folder

a renvoyé cette erreur, mais quand j'ai changé pour

# mount 192.168.2.101:/full/path/to/share /local/folder

cela a bien fonctionné ..

Il suffit de mettre la part exacte comme vous l'avez fait dans /etc/exports fichier


1
2017-11-30 19:20





Je suppose que cela s’est résolu lui-même ou a disparu sous une forme quelconque, car il est assez vieux.

Mais vérifiez que /proc/fs/nfsd est monté sur le serveur.

Si non: mount -t nfsd nfsd /proc/fs/nfsd


0
2017-08-15 06:14





Une fois, j'ai changé de matériel et d'OS - Fedora Core - et oublié que NetworkManager décidait que le contrôleur de réseau était maintenant inconnu. Au lieu de lui attribuer l'adresse IP fixe du contrôleur configuré, il le configurait sur DHCP, et donc sur le serveur. rejeté la connexion de ce système maintenant inconnu.

NetworkManager crée un nouveau fichier dans / etc / sysconfig / network-scripts / pour le "nouveau" contrôleur, l’ancien script étant conservé.

La solution a été d’éditer l’ancien "script" et de modifier la ligne (j’ai choisi de laisser l’ancienne ligne sous forme de commentaire) qui commence par "HWADDR" pour correspondre à la valeur équivalente dans le nouveau fichier, qui dans mon cas peut également être obtenue via ifconfig en tant que valeur "ether", puis supprimez le nouveau fichier. Redémarrez si nécessaire jusqu'à ce que l'ancienne adresse IP soit restaurée ....


0
2018-01-29 04:00