5 votes

loic.jaouen avatar

Le serveur NFS ne sert pas le partage après le redémarrage

Demandé el 15 de Novembre, 2016
Quand la question a-t-elle été
4947 affichage
Nombre de visites la question a
3 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'ai deux conteneurs Linode. Le conteneur A est notre serveur web à usage général. Il a occasionnellement besoin d'accéder à la boîte B, qui est configurée comme un serveur NFS.

Lorsque la boîte B redémarre, la boîte A ne peut accéder à aucun partage NFS, quoi que je fasse. Après plusieurs heures de dépannage, j'ai finalement réussi à résoudre le problème en une seule étape.

Après le redémarrage de la boîte B :

$ sudo service nfs restart

Ce sont deux boîtes CentOS 6.8, à jour. Les paquets liés à NFS ont tous été installés via yum, je crois. J'ai eu quelques difficultés à configurer l'ensemble ; le processus n'a pas été facile, mais après avoir redémarré le(s) service(s) nfs, tout fonctionne parfaitement.

Si je

$ sudo service --status-all

il n'y a pas de différence avant et après le redémarrage. C'est peut-être un problème de timing ? Mais je ne sais pas comment commencer à résoudre ce problème. Qu'est-ce que je peux faire ?

D'autres choses à noter :

  • J'utilise autofs pour monter automatiquement le partage à la demande depuis la boîte A, mais le partage ne se monte pas non plus manuellement.

  • Je passe mes journées sur des ordinateurs de bureau et des serveurs Windows et Mac, mais je gère des sites web sous Linux depuis de nombreuses années. Je sais faire ce que je dois faire, mais ce n'est pas mon domaine de prédilection et je passe beaucoup de temps à chercher sur Google comment faire de nouvelles choses.

Je ne sais même pas où vérifier. Je n'ai rien vu d'évident dans les journaux, mais dites-moi ce qu'il faut chercher et je posterai.

Mise à jour

Sur la boîte B :

 [shorowitz@BoxB ~]$ sudo chkconfig --list nfs
 nfs                0:off   1:off   2:on    3:on    4:on    5:on    6:off
 [shorowitz@BoxB ~]$ sudo chkconfig --list nfslock
 nfslock            0:off   1:off   2:on    3:on    4:on    5:on    6:off

Mise à jour 2

Après un nouveau redémarrage de BoxB, en exécutant

$ sudo showmount -e BoxB

de BoxA montre les points de montage attendus, mais je suis incapable de les monter. Il suffit de redémarrer nfs sur BoxB

 $ sudo service nfs restart
 Shutting down NFS daemon:                                  [  OK  ]
 Shutting down NFS mountd:                                  [  OK  ]
 Shutting down NFS services:                                [  OK  ]
 Shutting down RPC idmapd:                                  [  OK  ]
 FATAL: Module nfsd not found.
 FATAL: Error running install command for nfsd
 Starting NFS services:                                     [  OK  ]
 Starting NFS mountd:                                       [  OK  ]
 Starting NFS daemon:                                       [  OK  ]
 Starting RPC idmapd:                                       [  OK  ]

Et les montages sont immédiatement disponibles sur BoxA. Ces erreurs fatales apparaissent également lors des redémarrages suivants lorsque NFS fonctionne déjà, donc je ne sais pas si elles sont pertinentes (je pensais les avoir déjà postées).

Informations supplémentaires sur le journal

J'ai lancé la commande reboot à 9:29 le 15 nov.

 grep -i "nfs" /var/log/message*
 messages:Nov 15 09:29:08 BoxB kernel: nfsd: last server has exited, flushing export cache
 messages:Nov 15 09:29:54 BoxB kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
 messages:Nov 15 09:29:54 BoxB kernel: FS-Cache: Netfs 'nfs' registered for caching
 messages:Nov 15 09:29:54 BoxB kernel: NFS: Registering the id_resolver key type
 messages:Nov 15 09:29:54 BoxB kernel: nfs4filelayout_init: NFSv4 File Layout Driver Registering...
 messages:Nov 15 09:29:54 BoxB kernel: Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
 messages:Nov 15 09:29:54 BoxB kernel: xenfs: not registering filesystem on non-xen platform
 messages:Nov 15 09:29:54 BoxB rpc.mountd[2740]: NFS v4 mounts will be disabled unless fsid=0
 messages:Nov 15 09:29:54 BoxB kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
 messages:Nov 15 09:29:54 BoxB kernel: NFSD: starting 90-second grace period (net ****************)
 messages:Nov 15 09:33:39 BoxB kernel: nfsd: last server has exited, flushing export cache
 messages:Nov 15 09:33:40 BoxB kernel: NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
 messages:Nov 15 09:33:40 BoxB kernel: NFSD: starting 90-second grace period (net ****************)

Mise à jour 3 :

BoxB

 [shorowitz@BoxB ~]$ sudo chkconfig --list | egrep "nfs|rpc"
 nfs                0:off   1:off   2:on    3:on    4:on    5:on    6:off
 nfslock            0:off   1:off   2:on    3:on    4:on    5:on    6:off
 rpcbind            0:off   1:off   2:on    3:on    4:on    5:on    6:off
 rpcgssd            0:off   1:off   2:off   3:on    4:on    5:on    6:off
 rpcsvcgssd         0:off   1:off   2:off   3:off   4:off   5:off   6:off

 [shorowitz@BoxB ~]$ sudo iptables --list -n -v
 Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination         
     0     0 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
     0     0 REJECT     all  --  !lo    *       127.0.0.0/8          0.0.0.0/0           reject-with icmp-port-unreachable 
    18   710 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW icmp type 8 
   471 26200 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22 state NEW 
  204K  393M ACCEPT     all  --  *      *       {BoxA IP}            0.0.0.0/0           
  6721  754K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
  2859  168K LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables_INPUT_denied: ' 
  9229  628K REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination         
     0     0 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables_FORWARD_denied: ' 
     0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-port-unreachable 

 Chain OUTPUT (policy ACCEPT 278K packets, 8386M bytes)
  pkts bytes target     prot opt in     out     source               destination        

 [shorowitz@BoxB ~]$ sudo rpcinfo -p
program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100000    2   tcp    111  portmapper
 100000    4   udp    111  portmapper
 100000    3   udp    111  portmapper
 100000    2   udp    111  portmapper
 100024    1   udp  38148  status
 100024    1   tcp  45681  status
 100005    1   udp  37846  mountd
 100005    1   tcp  59259  mountd
 100005    2   udp  59934  mountd
 100005    2   tcp  42645  mountd
 100005    3   udp  33867  mountd
 100005    3   tcp  41823  mountd
 100003    2   tcp   2049  nfs
 100003    3   tcp   2049  nfs
 100003    4   tcp   2049  nfs
 100227    2   tcp   2049  nfs_acl
 100227    3   tcp   2049  nfs_acl
 100003    2   udp   2049  nfs
 100003    3   udp   2049  nfs
 100003    4   udp   2049  nfs
 100227    2   udp   2049  nfs_acl
 100227    3   udp   2049  nfs_acl
 100021    1   udp  37287  nlockmgr
 100021    3   udp  37287  nlockmgr
 100021    4   udp  37287  nlockmgr
 100021    1   tcp  37579  nlockmgr
 100021    3   tcp  37579  nlockmgr
 100021    4   tcp  37579  nlockmgr

Cela ne renvoie rien :

 grep -v "^#" /etc/sysconfig/nfs

BoîteA

 $ chkconfig --list | egrep "nfs|rpc"
 nfs                0:off   1:off   2:on    3:on    4:on    5:on    6:off
 nfslock            0:off   1:off   2:on    3:on    4:on    5:on    6:off
 rpcbind            0:off   1:off   2:on    3:on    4:on    5:on    6:off
 rpcgssd            0:off   1:off   2:off   3:on    4:on    5:on    6:off
 rpcsvcgssd         0:off   1:off   2:off   3:off   4:off   5:off   6:off

 $ iptables --list -n -v
 Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination         
  390K   58M ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0           
     0     0 REJECT     all  --  *      *       0.0.0.0/0            127.0.0.0/8         reject-with icmp-port-unreachable 
  990K 7850M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED 
     0     0 DROP       all  --  *      *       43.255.188.145       0.0.0.0/0           
     8   388 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:587 
 11864  608K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:25 
     1    40 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:636 
  4545  238K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:80 
  9759  553K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:443 
    24   960 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080 
   320 19152 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22 
    85  5681 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0           
  3254  194K LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied: ' 
  3634  227K DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

 Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination         
     0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0           

 Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source               destination         
 1360K 1907M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           

 $ rpcinfo -p
program vers proto   port  service
 100000    4   tcp    111  portmapper
 100000    3   tcp    111  portmapper
 100000    2   tcp    111  portmapper
 100000    4   udp    111  portmapper
 100000    3   udp    111  portmapper
 100000    2   udp    111  portmapper
 100024    1   udp  55882  status
 100024    1   tcp  58283  status
 100011    1   udp    875  rquotad
 100011    2   udp    875  rquotad
 100011    1   tcp    875  rquotad
 100011    2   tcp    875  rquotad
 100005    1   udp  43136  mountd
 100005    1   tcp  55047  mountd
 100005    2   udp  51117  mountd
 100005    2   tcp  42791  mountd
 100005    3   udp  44511  mountd
 100005    3   tcp  46535  mountd
 100003    2   tcp   2049  nfs
 100003    3   tcp   2049  nfs
 100003    4   tcp   2049  nfs
 100227    2   tcp   2049  nfs_acl
 100227    3   tcp   2049  nfs_acl
 100003    2   udp   2049  nfs
 100003    3   udp   2049  nfs
 100003    4   udp   2049  nfs
 100227    2   udp   2049  nfs_acl
 100227    3   udp   2049  nfs_acl
 100021    1   udp  43509  nlockmgr
 100021    3   udp  43509  nlockmgr
 100021    4   udp  43509  nlockmgr
 100021    1   tcp  38725  nlockmgr
 100021    3   tcp  38725  nlockmgr
 100021    4   tcp  38725  nlockmgr

 $ mount | grep nfs
 nfsd on /proc/fs/nfsd type nfsd (rw)
 sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)

Mise à jour du 14 novembre

 BoxA:

 $ cat /etc/auto.master.d/nfs
 xdata  -rw boxb:/srv/nfs/xdata
 xbackup    -rw boxb:/srv/nfs/xbackup
 zbackups   -rw boxb:/srv/nfs/zbackups

 $ mount | grep nfs
 mount |grep nfs
 nfsd on /proc/fs/nfsd type nfsd (rw)
 sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
 boxb:/srv/nfs/xdata on /mnt/nfs/xdata type nfs (rw,sloppy,vers=4,addr={boxb ip},clientaddr={boxa ip})
Demandé el 15 de Novembre, 2016 par loic.jaouen

3 votes

Avatar de Michael Hampton

serverfault.com/a/459732/126632

Commenté el 15 de Novembre, 2016 par Michael Hampton

2 votes

Avatar de Brett Levene

Vous devez vérifier que les services sont activés au niveau d'exécution correct : chkconfig --list nfslock y chkconfig --list nfs le confirmera.

Commenté el 15 de Novembre, 2016 par Brett Levene

1 votes

Avatar de loic.jaouen

Ajout des résultats de chkconfig --list. Je ne suis pas sûr de ce que les niveaux d'exécution devrait mais ils sont cohérents avec les autres services qui travaillent sur la botte.

Commenté el 16 de Novembre, 2016 par loic.jaouen
Afficher 5 autres commentaires

Réponses

Trop de publicités?

1voto

Dmitry Zayats avatar
Dmitry Zayats Points 1328

Pouvez-vous mettre à jour votre question avec plus d'informations ?
Sur le serveur NFS, exécutez

chkconfig --list | egrep "nfs|rpc"
iptables --list -n -v
rpcinfo -p

Le suivant ne devrait rien retourner si les paramètres de votre serveur nfs ne sont pas personnalisés.

grep -v "^#" /etc/sysconfig/nfs

Cependant, si vous utilisez iptables - il devrait être personnalisé. Voir ici
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-nfs-firewall-config.html

Sur votre client, exécutez 

chkconfig --list | egrep "nfs|rpc"
iptables --list -n -v
rpcinfo -p
mount | grep nfs

Si vous utilisez NFSV2 ou NFSV3, vous devez également faire tourner nfslock sur le client.

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s1-nfs-start.html

Ce qui semble étrange dans votre sortie lors du démarrage de NFS - c'est la ligne suivante

FATAL: Module nfsd not found.
 FATAL: Error running install command for nfsd

Et je viens de me rendre compte d'une chose - puisque vous fonctionnez sous openvz - le lien ci-dessous s'applique à votre situation. Voyez si cela peut vous aider

https://openvz.org/NFS_server_inside_container

Edit 1 : J'ai effectué des tests aujourd'hui sur des conteneurs openvz.
Message que vous voyez

FATAL: Module nfsd not found.
FATAL: Error running install command for nfsd

est inoffensif. Il est décrit ici https://openvz.org/NFS_server_inside_container

Je n'ai pas pu reproduire votre problème. Après le redémarrage du serveur nfs, le client nfs était toujours capable de parcourir les fichiers, de créer de nouveaux fichiers, de supprimer des fichiers du partage nfs.

Pouvez-vous maintenant poster votre configuration de montage automatique et aussi la sortie de

mount|grep nfs

De la boîte A, ce que vous avez déjà fait. Mais vous l'avez fait alors que le système de fichiers auto-monté était démonté. Donc maintenant sur la boite A, cd vers le répertoire auto-monté et ensuite lancez la commande ci-dessus. Cela donnera des informations sur les options qui ont été utilisées pendant le montage.

Aussi, la prochaine fois que vous redémarrez votre boîte B et que vous avez ce problème de montage automatique, à partir du site A, exécutez la commande suivante

netstat -anp|grep ipofB

Vous obtiendrez ainsi des informations sur les ports concernés.
Dans ce genre de situation, il est également bon de collecter des tcpdumps sur B et A.
J'ai tendance à penser qu'il n'y a rien de mal dans votre configuration - mais quelque chose de bizarre se passe avec iptables sur vzhosts. Pas dans vos conteneurs, mais sur les hôtes.

Ce que vous pouvez également essayer de faire est d'installer nmap sur votre hôte A et, au moment du problème, de scanner votre hôte B pour voir quels ports sont ouverts du point de vue de A (certains pourraient suggérer netstat ou ss, mais dans ce cas, il y a également un pare-feu hôte openvz devant le conteneur et nous ne savons pas s'ils bloquent quelque chose ou non).

Edit 2 (25 nov.) Il y a quelque chose de très étrange avec vos options de montage

Comparez vos résultats

$ mount | grep nfs
 mount |grep nfs
 nfsd on /proc/fs/nfsd type nfsd (rw)
 sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
 boxb:/srv/nfs/xdata on /mnt/nfs/xdata type nfs (rw,sloppy,vers=4,addr={boxb ip},clientaddr={boxa ip})

A la mienne ci-dessous. Voici mon /etc/auto.misc. La ligne 6 est par défaut. Ligne 16, j'ai ajouté

[root@vznfsclient /]# egrep -vn "^#|^$" /etc/auto.misc
6:cd            -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
16:nfs          -fstype=nfs             192.168.0.54:/nfs_export

Donc, quand je me connecte à /misc/nfs, mon partage est monté. Mais regardez les options par défaut à la ligne 12.

[root@vznfsclient ~]# mount|egrep -n "nfs|auto"
4:nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
5:sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
10:/etc/auto.misc on /misc type autofs (rw,relatime,fd=6,pgrp=768,timeout=300,minproto=5,maxproto=5,indirect)
11:-hosts on /net type autofs (rw,relatime,fd=12,pgrp=768,timeout=300,minproto=5,maxproto=5,indirect)
12:192.168.0.54:/nfs_export/ on /misc/nfs type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.54,mountvers=3,mountport=42089,mountproto=udp,local_lock=none,addr=192.168.0.54)

D'abord c'est nfsv3 et ça utilise udp. Ok udp on peut le changer en tcp en changeant /etc/auto.misc en ceci

[root@vznfsclient /]# egrep -vn "^#|^$" /etc/auto.misc
6:cd            -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
16:nfs          -fstype=nfs,proto=tcp   192.168.0.54:/nfs_export

Et les options de montage changeront en

192.168.0.54:/nfs_export/ on /misc/nfs type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.54,mountvers=3,mountport=45378,mountproto=tcp,local_lock=none,addr=192.168.0.54)

Lorsque j'essaie d'utiliser dans /etc/auto.misc -fstype=nfs4 - Je ne peux même pas accéder à /misc/nfs, ce qui est logique puisque selon openvz, nfsv4 n'est pas supporté dans les conteneurs. https://openvz.org/NFS_server_inside_container

Remarquez que vous avez dans vos options de montage sloppy et simple rw . Cela signifie essentiellement que

  1. Les options passées à mount.nfs ne sont pas exactement correctes, donc il essaie de les contourner. Lisez man mount.nfs et cherchez /sloppy.
  2. Je suppose qu'il essaie d'utiliser nfsv4. Je ne sais même pas comment ça marche si ce n'est pas supporté par le conteneur.

Je vous suggère de modifier vos cartes de montage automatique avec la syntaxe correcte (voir mon exemple) ou de voir les exemples ici. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html

Et le test. Je viens de faire des tests avec autofs dans ces 2 mêmes conteneurs fonctionnant sur 2 hôtes openvz différents - et après le redémarrage du serveur nfs - le client est toujours satisfait.

Edit 3 Je ne peux même pas reproduire votre scénario. J'ai modifié mon /etc/auto.misc comme suit, ce qui est à peu près ce que vous avez

[root@vznfsclient nfs]# egrep -nv "^#|^$" /etc/auto.misc
6:cd            -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
16:nfs          -rw                     192.168.0.54:/nfs_export

Et après le redémarrage et le cd /misc/nfs j'ai toujours ceci

[root@vznfsclient nfs]# mount|grep nfs
nfsd on /proc/fs/nfsd type nfsd (rw,relatime)
sunrpc on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw,relatime)
192.168.0.54:/nfs_export/ on /misc/nfs type nfs (rw,relatime,vers=3,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.0.54,mountvers=3,mountport=46453,mountproto=udp,local_lock=none,addr=192.168.0.54)

Donc dans mon cas, il essaie correctement d'utiliser nfsv3.

La seule chose qui reste à faire maintenant est

Activer le débogage dans le fichier /etc/autofs.conf

[root@vznfsclient nfs]# grep -i debug /etc/autofs.conf|grep -v "^#"
    logging = debug

Activer la sévérité du débogage pour être envoyé à /var/log/messages dans le /etc/rsyslog.conf . Changez ceci

[root@vznfsclient nfs]# grep info /etc/rsyslog.conf
*.info;mail.none;authpriv.none;cron.none                -/var/log/messages

A ceci (.info à .debug)

[root@vznfsclient nfs]# grep debug /etc/rsyslog.conf
*.debug;mail.none;authpriv.none;cron.none                -/var/log/messages

Redémarrez autofs et rsyslog, puis lorsque vous passez à l'emplacement monté automatiquement, vous devriez voir une sortie de débogage dans le fichier /var/log/messages

Voici le résultat de mon système de test

Nov 25 03:06:00 vznfsclient automount[583]: attempting to mount entry /misc/nfs
Nov 25 03:06:00 vznfsclient automount[583]: lookup_mount: lookup(file): looking up nfs
Nov 25 03:06:00 vznfsclient automount[583]: lookup_mount: lookup(file): nfs -> -rw#011#011#011192.168.0.54:/nfs_export
Nov 25 03:06:00 vznfsclient automount[583]: parse_mount: parse(sun): expanded entry: -rw#011#011#011192.168.0.54:/nfs_export
Nov 25 03:06:00 vznfsclient automount[583]: parse_mount: parse(sun): gathered options: rw
Nov 25 03:06:00 vznfsclient automount[583]: parse_mount: parse(sun): dequote("192.168.0.54:/nfs_export") -> 192.168.0.54:/nfs_export
Nov 25 03:06:00 vznfsclient automount[583]: parse_mount: parse(sun): core of entry: options=rw, loc=192.168.0.54:/nfs_export
Nov 25 03:06:00 vznfsclient automount[583]: sun_mount: parse(sun): mounting root /misc, mountpoint nfs, what 192.168.0.54:/nfs_export, fstype nfs, options rw
Nov 25 03:06:00 vznfsclient automount[583]: mount_mount: mount(nfs): root=/misc name=nfs what=192.168.0.54:/nfs_export, fstype=nfs, options=rw
Nov 25 03:06:00 vznfsclient automount[583]: mount_mount: mount(nfs): nfs options="rw", nobind=0, nosymlink=0, ro=0
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: called with host 192.168.0.54(192.168.0.54) proto 6 version 0x40
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: called with host 192.168.0.54(192.168.0.54) proto 6 version 0x70
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: nfs v3 rpc ping time: 0.000366
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: host 192.168.0.54 cost 365 weight 0
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: called with host 192.168.0.54(192.168.0.54) proto 17 version 0x70
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: nfs v3 rpc ping time: 0.000507
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: nfs v2 rpc ping time: 0.000692
Nov 25 03:06:00 vznfsclient automount[583]: get_nfs_info: host 192.168.0.54 cost 599 weight 0
Nov 25 03:06:00 vznfsclient automount[583]: prune_host_list: selected subset of hosts that support NFS3 over TCP
Nov 25 03:06:00 vznfsclient automount[583]: mount_mount: mount(nfs): calling mkdir_path /misc/nfs
Nov 25 03:06:00 vznfsclient automount[583]: mount_mount: mount(nfs): calling mount -t nfs -s -o rw 192.168.0.54:/nfs_export /misc/nfs
Nov 25 03:06:00 vznfsclient automount[583]: spawn_mount: mtab link detected, passing -n to mount
Nov 25 03:06:00 vznfsclient automount[583]: mount(nfs): mounted 192.168.0.54:/nfs_export on /misc/nfs
Nov 25 03:06:00 vznfsclient automount[583]: ioctl_send_ready: token = 28
Nov 25 03:06:00 vznfsclient automount[583]: mounted /misc/nfs
Répondu el 23 de Novembre, 2016 par Dmitry Zayats (1328 Points )

0 votes

Avatar de loic.jaouen

J'ai ajouté les informations demandées - bien que ce soit pendant que NFS travaillait sur les deux. Faites-moi savoir s'il y a quelque chose en particulier que vous voulez voir lorsque les machines sont dans un état où les montages NFS ne sont pas disponibles.

Commenté el 23 de Novembre, 2016 par loic.jaouen

0 votes

Avatar de Dmitry Zayats

Pouvez-vous maintenant poster vos cartes de montage automatique ? Et aussi la sortie de l mount|grep nfs lorsque vous êtes dans le répertoire monté automatiquement sur la boîte A. Cela donnera des informations sur les options utilisées pendant le montage automatique. De même, si vous rencontrez un problème après le redémarrage du boîtier B, accédez au répertoire auto-monté du boîtier A et, dans une autre fenêtre de terminal, exécutez les commandes suivantes netstat -anp|grep ipofBoxB1 cela montrera les ports auxquels A essaie d'accéder sur B.

Commenté el 24 de Novembre, 2016 par Dmitry Zayats

0 votes

Avatar de loic.jaouen

Ce n'est pas un problème d'autofs. La première chose que j'ai faite a été de désactiver autofs, et d'essayer de les monter manuellement. Si le serveur redémarre, cela ne fonctionne pas non plus. Redémarrez nfs sur le serveur, exécutez exactement la même commande de montage manuel sur le client, et cela fonctionne bien (tout comme l'utilisation de autofs, si elle est activée, fonctionne automatiquement).

Commenté el 28 de Novembre, 2016 par loic.jaouen
Afficher 1 autres commentaires

0voto

ewwhite avatar
ewwhite Points 193555

Deux choses... CentOS 6.5 n'est pas à jour. Cela vaut la peine de prévoir de mettre votre système d'exploitation à la version actuelle (6.8 pour le moment).

Essayez le ntsysv au lieu de la commande chkconfig . Vous pouvez vous assurer que le démon du serveur NFS est activé (coché) au démarrage.

Activez le netfs car il est utile pour s'assurer que les clients du système de fichiers réseau montent les systèmes de fichiers requis au démarrage.

enter image description here

Bonne chance !

Répondu el 20 de Novembre, 2016 par ewwhite (193555 Points )

0 votes

Avatar de loic.jaouen

Oups. CentOS 6.8. Je vais vérifier le reste

Commenté el 20 de Novembre, 2016 par loic.jaouen

0 votes

Avatar de loic.jaouen

Ntsysv ne semble pas faire partie de CentOS 6 ?

Commenté el 20 de Novembre, 2016 par loic.jaouen

0 votes

Avatar de loic.jaouen

Et netfs est activé pour le niveau d'exécution 2 3 4 5

Commenté el 20 de Novembre, 2016 par loic.jaouen

0voto

mc0e avatar
mc0e Points 5736

Tout d'abord, NFS n'est généralement pas très fiable pour le partage de fichiers entre serveurs. Le fait que BoxB redémarre ou devienne indisponible alors que BoxA a des montages actifs est problématique, tout comme le fait de retirer un disque d'un système en fonctionnement. Toutes sortes de choses peuvent être laissées dans des états bizarres.

Vous ne nous avez pas donné beaucoup d'informations sur l'usage que vous faites du support, mais envisagez des alternatives à NFS. Si vous donnez quelques indications sur l'usage que vous en faites, je peux probablement vous suggérer des alternatives. GFS, GlusterFS, rsync, lsyncd, ou un service basé sur HTTP(S) me viennent à l'esprit comme des possibilités qui pourraient s'appliquer dans au moins certaines circonstances.

En ce qui concerne votre situation actuelle, je suppose que quelque chose reste suspendu à votre montage lorsque BoxB s'arrête, et que la partie importante du redémarrage du serveur est d'arrêter ce qui est déjà en cours d'exécution. Si c'est le cas, vous devriez être en mesure d'éteindre les deux boîtes, puis de démarrer BoxA et ensuite BoxB, et le montage devrait toujours démarrer correctement. Si je ne me trompe pas, je pense que les journaux de BoxA sont plus pertinents que ceux de BoxB que vous avez partagés avec nous. Je regarderais aussi la table de montage pour trouver des indices.

Répondu el 22 de Novembre, 2016 par mc0e (5736 Points )

0 votes

Avatar de loic.jaouen

Non. J'ai éteint les deux. J'ai démarré A et je l'ai laissé reposer pendant un moment. J'ai démarré B et l'ai laissé reposer un moment. Impossible de monter le partage NFS. Après avoir redémarré le service NFS sur BoxB, BoxA est capable presque instantanément de monter les partages.

Commenté el 22 de Novembre, 2016 par loic.jaouen

Questions connexes

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X