Назад | Перейти на главную страницу

Сервер NFS не обслуживает общий ресурс после перезагрузки

У меня есть два контейнера с линодом. Блок A - это наш веб-сервер общего назначения. Иногда ему требуется доступ к Box B, который настроен как сервер NFS.

Когда Box B перезагружается, Box A не может получить доступ к общим ресурсам NFS, что бы я ни делал. После нескольких часов поиска и устранения неполадок я наконец смог сузить круг вопросов до одношагового исправления.

После перезагрузки Box B:

$ sudo service nfs restart

Это обе последние версии CentOS 6.8. Думаю, все пакеты, связанные с NFS, были установлены через yum. У меня действительно были проблемы с настройкой всего этого; это был непростой процесс, но после перезапуска службы (служб) nfs все работает отлично.

Если я

$ sudo service --status-all

нет разницы до и после перезапуска. Может дело в сроках? Но я даже не знаю, как это снимать. Что я могу сделать?

Другие примечания:

Я использую autofs для автоматического монтирования общего ресурса по запросу из Box A, но общий ресурс также не будет монтироваться вручную
Я провожу дни на компьютерах и серверах Windows и Mac, но многие годы я запускаю веб-сайты на Linux. Я хорошо разбираюсь в том, что мне нужно делать, но это не моя область комфорта, и я трачу много времени на поиски новых вещей в Google.

Я даже не знаю где проверить. Я не увидел ничего очевидного в журналах, но скажите, что искать, и я опубликую.

Обновить

В коробке 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

Обновление 2

После новой перезагрузки BoxB запускается

$ sudo showmount -e BoxB

from BoxA показывает ожидаемые точки монтирования, но я не могу их смонтировать. Просто перезапустите nfs на 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  ]

И крепления сразу доступны на BoxA. Эти фатальные ошибки появляются и при последующих перезапусках, когда NFS уже работает, поэтому я не знаю, насколько они актуальны (я думал, что уже опубликовал их).

Дополнительная информация журнала

Я дал команду перезагрузки в 9:29 15 ноября.

 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 ****************)

Обновление 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

Это ничего не возвращает:

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

BoxA

 $ 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)

Обновление 14 ноября

 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})

Можете ли вы дополнить свой вопрос дополнительной информацией?
На сервере NFS запустить

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

Далее ничего не должно возвращать, если настройки вашего сервера nfs не настроены.

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

Однако, если вы используете iptables - его нужно настроить. Посмотреть здесь
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-nfs-firewall-config.html

На вашем клиенте запустить

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

Если вы используете NFSV2 или NFSV3, вам также понадобится nfslock, работающий на клиенте.

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

Что выглядит странно в вашем выводе при запуске NFS - это строка ниже

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

И я только что понял одну вещь - поскольку вы работаете на openvz, ссылка ниже применима к вашей ситуации. Посмотрим, поможет ли это

https://openvz.org/NFS_server_inside_container

Изменить 1: Сегодня я провел тесты на контейнерах openvz.
Сообщение, которое вы видите

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

безвреден. Это описано здесь https://openvz.org/NFS_server_inside_container

Я не смог воспроизвести вашу проблему. После перезагрузки сервера nfs - клиент nfs все еще мог просматривать файлы, создавать новые файлы, удалять файлы из общего ресурса nfs.

Можете ли вы опубликовать конфигурацию автоматического монтирования, а также вывод

mount|grep nfs

Из коробки А, которую вы уже сделали. Но вы сделали это, когда автоматически смонтированная файловая система была отключена. Итак, теперь в Box A перейдите к автоматически смонтированному каталогу, а затем выполните команду выше. Это даст информацию о том, какие параметры использовались во время монтирования.

Также в следующий раз, когда вы перезагрузите свой Box B, и у вас возникнет эта проблема с автоматическим монтированием - с сайта A запустите эту команду

netstat -anp|grep ipofB

Это даст информацию о задействованных портах.
В таких ситуациях также хорошо собирать tcpdump на B и A.
Я склонен думать, что с вашей конфигурацией все в порядке, но что-то странное происходит с iptables на vzhosts. Не в ваших контейнерах, а на хостах.

Что вы также можете попробовать сделать, так это установить nmap на свой хост A и во время проблемы просканировать ваш хост B, чтобы увидеть, какие порты открыты с точки зрения A (некоторые могут предложить netstat или ss, но в в этом случае перед контейнером также есть брандмауэр хоста openvz, и мы не знаем, блокируют ли они что-то или нет)

Редактировать 2 (25 ноября) Что-то очень странное с вашими вариантами крепления

Сравните ваш вывод

$ 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})

К моему ниже. Вот мой /etc/auto.misc. Строка 6 по умолчанию. Строка 16 я добавил

[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

Итак, когда я нажимаю на / misc / nfs - моя доля монтируется. Но посмотрите на параметры по умолчанию в строке 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)

Сначала это nfsv3, использующий udp. Хорошо, udp, мы можем перейти на tcp, изменив /etc/auto.misc на это

[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

И параметры монтирования изменятся на

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)

Когда я пытаюсь использовать в /etc/auto.misc -fstype=nfs4 - Я даже не могу перейти к / misc / nfs, что имеет смысл, поскольку для каждого openvz nfsv4 не поддерживается внутри контейнера https://openvz.org/NFS_server_inside_container

Обратите внимание, что у вас есть в параметрах крепления sloppy и просто rw. Это в основном означает, что

Параметры, переданные в mount.nfs, не совсем верны, поэтому он пытается обойти это. Прочтите man mount.nfs и найдите / sloppy.
Я предполагаю, что он пытается использовать nfsv4. Даже не знаю, как это работает, если не поддерживается внутри контейнера.

Я бы предложил изменить ваши карты автоматического монтирования на правильный синтаксис (см. Мой пример) или посмотреть примеры здесь https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html

И тест. Я только что провел тесты с autofs в тех же 2 контейнерах, запущенных на 2 разных хостах openvz, и после перезагрузки сервера nfs клиент все еще доволен.

Редактировать 3 Я даже не могу воспроизвести ваш сценарий. Я изменил свой /etc/auto.misc на ниже, что в значительной степени то, что у вас есть

[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

И после перезагрузки и cd / misc / nfs у меня осталась эта

[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)

Итак, в моем случае он правильно пытается использовать nfsv3.

Единственное, что осталось сделать, это

Активируйте отладку в /etc/autofs.conf

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

Включить отправку уровня серьезности отладки /var/log/messages в /etc/rsyslog.conf. Изменить это

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

К этому (от .info до .debug)

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

Перезапустите autofs и rsyslog, а затем, когда вы перейдете в автоматически смонтированное местоположение, вы должны увидеть вывод отладки в /var/log/messages

Вот результат моей тестовой системы

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

Во-первых, NFS обычно не так надежен для обмена файлами между серверами. Перезагрузка BoxB или его недоступность по иным причинам, когда BoxA имеет активные крепления, проблематично во многом так же, как вытаскивание диска из работающей системы. В нечетном состоянии можно оставить все, что угодно.

Вы не дали нам много информации о том, для чего вы используете монтирование, но рассмотрите альтернативы NFS. Если вы укажете, для чего вы это делаете, я, вероятно, могу предложить альтернативы. На ум приходят GFS, GlusterFS, rsync, lsyncd или службы на основе HTTP (S), которые могут применяться по крайней мере в некоторых обстоятельствах.

Что касается вашей текущей ситуации, я предполагаю, что что-то осталось висеть на вашем монтировании, когда BoxB выходит из строя, и что важная часть перезапуска сервера завершает то, что уже работает. Если это верно, то вы сможете выключить оба бокса, затем запустить BoxA, а затем BoxB, и монтировка все равно должна запуститься нормально. Если я здесь, то я думаю, что журналы на BoxA более актуальны, чем журналы из BoxB, которыми вы поделились с нами. Я бы тоже посмотрел на монтажный стол в поисках подсказок.

Пара вещей ... CentOS 6.5 устарела. Стоит запланировать довести вашу ОС до текущей версии (в настоящее время 6.8).

Попробуйте ntsysv команда вместо chkconfig. Вы можете убедиться, что демон сервера NFS включен (отмечен) при загрузке.

Включите netfs service, поскольку это помогает гарантировать, что клиенты сетевой файловой системы монтируют необходимые файловые системы при загрузке.

Удачи!