mount.nfs: accès refusé par le serveur lors du montage sur des machines Ubuntu?

65

J'ai trois machines en production -

machineA    10.66.136.129
machineB    10.66.138.181
machineC    10.66.138.183

et Ubuntu 12.04 est installé sur toutes ces machines et j’ai un accès root à toutes ces trois machines.

Maintenant je suis supposé faire ci-dessous des choses dans mes machines ci-dessus -

Create mount point /opt/exhibitor/conf
Mount the directory in all servers.
 sudo mount <NFS-SERVER>:/opt/exhibitor/conf /opt/exhibitor/conf/

J'ai déjà créé un /opt/exhibitor/confrépertoire dans ces trois machines, comme mentionné ci-dessus.

Maintenant, j'essaie de créer un point de montage. J'ai donc suivi le processus ci-dessous -

Installez les fichiers de support NFS et le serveur de noyau NFS sur les trois ordinateurs ci-dessus.

$ sudo apt-get install nfs-common nfs-kernel-server

Créer le répertoire partagé sur les trois machines ci-dessus

$ mkdir /opt/exhibitor/conf/

Edité le /etc/exportset ajouté comme ceci dans les trois machines ci-dessus -

# /etc/exports: the access control list for filesystems which may be exported
#               to NFS clients.  See exports(5).
#
# Example for NFSv2 and NFSv3:
# /srv/homes       hostname1(rw,sync,no_subtree_check) hostname2(ro,sync,no_subtree_check)
#
# Example for NFSv4:
# /srv/nfs4        gss/krb5i(rw,sync,fsid=0,crossmnt,no_subtree_check)
# /srv/nfs4/homes  gss/krb5i(rw,sync,no_subtree_check)
#
/opt/exhibitor/conf/     10.66.136.129(rw)
/opt/exhibitor/conf/     10.66.138.181(rw)
/opt/exhibitor/conf/     10.66.138.183(rw)

J'ai essayé de monter sur machineA comme ci-dessous de machineB et machineC et cela me donne cette erreur-

root@machineB:/# sudo mount -t nfs 10.66.136.129:/opt/exhibitor/conf /opt/exhibitor/conf/
mount.nfs: access denied by server while mounting 10.66.136.129:/opt/exhibitor/conf

root@machineC:/# sudo mount -t nfs 10.66.136.129:/opt/exhibitor/conf /opt/exhibitor/conf/
mount.nfs: access denied by server while mounting 10.66.136.129:/opt/exhibitor/conf

Mon /etc/exportsdossier a- t-il l' air bon? Je suis à peu près sûr que j'ai foiré mon exportsdossier. Comme j'ai le même contenu dans les trois machines du fichier export.

Une idée de ce que je fais de mal ici? Et quel sera le bon /exportsfichier ici?

arsenal
la source
1
FYI double vérification des autorisations sur l'hôte / client. Si l'hôte NFS dispose d'autorisations 0750ou si 0700le client essayant de monter risque fort d'échouer avec le même message d'erreur. J'ai changé d'hôte de 0750à 0755et puis l'erreur est partie et tout allait bien.
Trevor Boyd Smith

Réponses:

72

exportfs

Lorsque vous créez un /etc/exportsfichier sur un serveur, vous devez vous assurer de l'exporter. En règle générale, vous voudrez exécuter cette commande:

$ exportfs -a

Cela exportera toutes les entrées du fichier d'exportations.

showmount

L'autre chose que je vais souvent faire est d'utiliser d'autres commandes pour vérifier toutes les machines qui exportent des partages NFS vers le réseau à l'aide de la showmountcommande.

$ showmount -e <NFS server name>

Exemple

Disons par exemple que je suis connecté à scully.

$ showmount -e mulder
Export list for mulder:
/export/raid1/isos     192.168.1.0/24
/export/raid1/proj     192.168.1.0/24
/export/raid1/data     192.168.1.0/24
/export/raid1/home     192.168.1.0/24
/export/raid1/packages 192.168.1.0/24

fstab

Pour les monter lors de l’amorçage, vous devez ajouter cette ligne à vos ordinateurs clients qui souhaitent utiliser les montages NFS.

server:/shared/dir /opt/mounted/dir nfs rsize=8192,wsize=8192,timeo=14,intr

montage automatique

Si vous êtes sur le point de redémarrer ces serveurs, je vous suggère fortement de vous pencher sur la configuration de automounting ( autofs) au lieu d’ajouter ces entrées /etc/fstab. C'est un peu plus de travail mais cela en vaut la peine.

Cela vous permettra de redémarrer les serveurs de manière plus indépendante les uns des autres et ne créera également le montage NFS que lorsque cela est réellement nécessaire et / ou utilisé. Quand il tourne au ralenti, il sera démonté.

Références

slm
la source
Merci pour la suggestion. Je viens de faire cela et maintenant cela fonctionne bien. Au lieu de courir exportfs -a, j'ai couru exportfs -rv. Y a-t-il une différence entre ceux-ci? Et dans mon cas, showmount -e 10.66.136.129je vais faire de machineB et machineC. droite?
arsenal
1
@ TechGeeky - pas vraiment. exportfs -rvfait juste une réexportation + est verbeuse. Le -ava tout exporter. En ce qui concerne showmount -eoui, vous pouvez l'exécuter à partir de ces machines ou de celle servant les actions.
slm
ok .. Merci, sens maintenant .. Une dernière chose. Je crois qu'il y a encore une chose à cette chose de point de montage, fichier fstab .. correct? Maintenant quel fichier fstab de machine, je suis supposé modifier? Et quel contenu je suis supposé ajouter là? Une idée?
arsenal
@TechGeeky voir les mises à jour. Vous ajoutez des entrées aux clients qui souhaitent utiliser les partages NFS.
slm
1
Sur Ubuntu, vous devez d’abord installer nfs-kernel-server pour que exportfs soit disponible. Source: manpages.ubuntu.com/manpages/trusty/man8/exportfs.8.html
Flickerfly
40

J'ai vu la même erreur ( mount.nfs: access denied by server while mounting...) et le problème a été résolu par -o v3option comme suit:

$ sudo mount -o v3 a-nfs-server:/path/to/export /path/to/mount
  • Le serveur est Ubuntu 14.04 LTS 64bit.
  • Le client est CentOS 6.5 64bit.
Fumisky Wells
la source
2
Aucun des autres n'a aidé, c'était la solution, dans mon cas.
Urhixidur
1
J'ai essayé celui-ci et j'ai mount.nfs: Connection timed out. (Le client est Ubuntu 14.04 LTS 64 bits. Le serveur est un NFS QNAP avec QTS 4.0.2 2016/01/09.)
Steve
Oui, lorsque j'ai mis mon serveur à niveau vers Ubuntu 16, le problème et la solution étaient résolus.
Sridhar Sarnobat
2
Sois prudent avec ça. NFSv3 est ancien et obsolète depuis longtemps. cela ne devrait vraiment plus être utilisé (et c'était même vrai quand cet article a été écrit).
Michael Hampton
7

Dans mon cas, utilise nfs4 comme suit:

$ sudo mount -t nfs4 nom du serveur: / / chemin / vers / mount

Dans le /etc/exportfichier sur le serveur

/Path/to/export 192.168.1.0/24(rw,sync,fsid=0,no_root_squash,crossmnt,no_subtree_check,no_acl)

fsid=0rend le /Path/to/exportrépertoire racine lorsque vous montez le partage.

crossmnt, car j’ai accès à d’autres lecteurs dans le système de fichiers exporté.

no_root_squash, car je veux accéder en tant qu’utilisateur root (su) du côté client. Je suis à peu près sûr que je suis le seul à pouvoir le faire sur mon réseau local.

Le serveur et les clients sont Ubuntu 14.04 64bit.

Si vous voulez utiliser nfs3, la réponse de @fumisky-wells fonctionne également pour moi.

Victe
la source
Vous avez gagné un vote positif monsieur; J'ai un NAS, donc modding le fichier / etc / export n'est pas une option, mais spécifier le chemin complet a fait l'affaire. bien joué.
MDMoore313
4

Je recevais le même message d'erreur et mon problème était dû au fait que la machine cliente avait deux interfaces réseau connectées au même réseau local. Le serveur avait été configuré pour s’attendre à une adresse IP spécifique et le trafic était acheminé sur la deuxième interface dotée d’une adresse IP DHCP. Donc, je viens de configurer la deuxième interface pour avoir une adresse IP statique et également ajouté la deuxième adresse IP statique à la configuration du serveur.

majjinateur
la source
J'aurais aimé que ce soit plus vers le haut, c'est exactement ce qui se passait dans mon cas
Brian Leishman
3

/etc/exportsdoit être modifié sur la machine du serveur NFS , et non sur les clients, comme vous le dites, comme il est vérifié par le serveur NFS lorsqu'un client demande l'accès à un partage.

Si vous mettez les informations suivantes /etc/exportssur le serveur NFS, cela devrait fonctionner:

/opt/exhibitor/conf 10.66.136.129(rw)
/opt/exhibitor/conf 10.66.138.181(rw)
/opt/exhibitor/conf 10.66.138.183(rw)
Chris Down
la source
J'ai déjà cela dans mon fichier d'export sur machineA. Et puis je le monte à partir de machineB et machineC et cela ne fonctionne pas du tout. Est-il possible que j'ai ajouté les mêmes informations dans les trois machines du fichier d'exportations, cela pose-t-il un problème? Je devrais ajouter que dans machineA?
arsenal
1
@TechGeeky Avez-vous rechargé les exportations NFS après avoir utilisé cela exportfs -a?
Chris Down
Je viens de faire cela et maintenant cela fonctionne bien. J'essaie de mieux comprendre tout cela, alors ma première question est la suivante: machineA est un serveur NFS et machineB et machineC sont des clients .. Correct? La deuxième question est, si machineA est mon serveur NFS, alors seulement dans le fichier / etc / exports de machineA, j'ajouterai les trois lignes ci-dessus comme vous l'avez mentionné dans votre solution et nous ne toucherons pas le fichier exports de machineB et machineC? Correct?
arsenal
@TechGeeky Tant que vous montez un partage sur la machine A, c'est correct dans les deux cas.
Chris Down
Merci. Maintenant, je comprends cela beaucoup mieux. Pourquoi j'ai posé cette question parce que j'ai également des éléments similaires dans l'environnement de transfert. Et ce que j'ai fait dans ces trois machines dans l'environnement de transfert, j'ai ajouté les trois mêmes lignes dans tous mes fichiers / etc / exports de trois machines au lieu de l'ajouter uniquement dans machineA mais cela fonctionne toujours bien. Et maintenant j'ai compris le concept dans son ensemble plus clairement. Merci pour l'aide.
arsenal
2

Si nfs-client tente de monter un partage exporté dans un conteneur linux, celui-ci doit s'exécuter en mode privilégié.

En cas de docker;

$ docker run -it --rm --privileged ubuntu:14.04

efesaid
la source
2

Pour moi, le problème était que j'utilisais l'adresse IP du serveur à la /etc/exports/place de celle du client .

Le fait est que vous devez mettre tous les ips auxquels vous accordez l’accès sur le serveur. /etc/exports/

Vanuan
la source
1

Après avoir lutté avec ce même message d'erreur pendant des heures, mon problème s'est avéré être rien de plus compliqué que de bonnes anciennes autorisations de fichiers Linux sur l'hôte NFS.

Le dossier que j'essayais de partager ( /home/foo/app/share) disposait des autorisations appropriées, mais étant donné que le répertoire de base de l'utilisateur ( /home/foo) était en 0750mode, NFS n'était pas en mesure de le parcourir pour accéder au répertoire partagé.

Dès que j'ai mis le répertoire de base de l'utilisateur en mode 0751, le service NFS a pu y accéder et j'ai pu monter le partage à partir de mon ordinateur client.

Dale Anderson
la source
0

Pour moi, le problème était que mon routeur avait changé l'adresse IP utilisée du client, de sorte que l'entrée /etc/exportssur la machine serveur permettait uniquement l'accès à une adresse IP qui n'était plus utilisée.

Alex
la source
0

La même chose pourrait se produire si vous essayez de monter un partage NFS sur une instance de Virtual Box avec un adaptateur réseau configuré en tant que NAT.

Le choix Bridged Adapterdans les paramètres réseau de la machine virtuelle résout ce problème.

mkaptur
la source
0

Je sais que c'est un vieux fil, mais mon problème avait à voir avec LXC et AppArmor .

La suppression d' AppArmor ou l'ajout d'un profil d'exception l'a corrigé.

Josh
la source
voir aussi unix.stackexchange.com/q/396678/231113 au cas où vous utiliseriez proxmox
myrdd
0

Cette erreur peut également être provoquée en essayant de monter un chemin crypté. (Par exemple, dans votre répertoire personnel, si vous avez choisi de le chiffrer)

utilisateur3737396
la source
0

La seule solution qui a fonctionné pour moi était d’exporter les systèmes de fichiers /srv. Il semble que ceci soit une limitation (ou une option par défaut, au moins) de NFSv4.

Étant donné que j'essayais d'exporter une clé USB /mediavers laquelle un montage automatique était effectué , il me fallait un moyen de le monter /srv. Pour cela:

sudo mkdir /srv/videos
sudo mount --bind /media/jim/wdportable/videos /srv/videos

Et dans /etc/exports:

/srv/videos 192.168.0.200(ro)

Lorsque j'exportais /media/jim/wdportable/videosdirectement, la tentative de montage sur le client aboutissait toujours à mount.nfs: access denied by server.

La -o v3solution a fonctionné, mais je ne voulais pas forcer v3.

Jim Stewart
la source
2
Je peux presque garantir que cela aurait été dû aux autorisations sur le /media/jimdossier. Si le répertoire que vous essayez de partager est (ou est à l'intérieur de) un répertoire avec seulement 700ou 750mode, NFS ne pourra pas y accéder. Si vous changiez /media/jimen 751, cela fonctionnerait probablement.
Dale Anderson
@DaleAnderson a raison. Après un succès sudo mount -o v3 192.168.0.200:"/media/pi/mydrive" /mnt/nfs-share(Raspbian sur Raspi 3 B +), j'ai également essayé de sudo chmod 751 /media/pi. Par la suite, je ne l' ai pas besoin -o v3plus: sudo mount 192.168.0.200:"/media/pi/mydrive" /mnt/nfs-sharefait le travail (après démontant). Merci beaucoup à @DaleAnderson.
Thomas Praxl le
C'est probablement le problème. Je suppose que je suis habitué aux temps anciens où le serveur NFS fonctionnait en tant que root et exportait à l'aveuglette ce qu'il avait été dit. Je vais tester cela.
Jim Stewart
0

Il convient de noter qu'une page liée qui m'amène ici avait ma bonne réponse, à savoir que vous ne pouvez PAS utiliser de caractère générique * dans l'adresse IP lors de l'exportation. Il s'agit soit * (toutes les adresses IP), soit utilisé comme caractère générique dans les noms de domaine IE: * .domain.com.

Ex: c'est correct

/Path/to/export 192.168.1.0/24(flags)

Cela ne fonctionnera pas (ou est au moins incorrect), mais a fonctionné pour moi pendant des années jusqu'à ce que j'essaye de monter l'exportation à partir d'une machine virtuelle Fedora.

/Path/to/export 192.168.1.*(flags)
FreeSoftwareServers
la source
Je pense que la raison de son échec est peut-être NFSv4 car je sais que Fedora saigne de nouvelles technologies et que mes anciennes machines virtuelles ont bien fonctionné, mais utilisaient probablement une version plus ancienne de NFS. Juste une supposition.
FreeSoftwareServers