Как разрешить, когда IP-адрес сервера NFS изменяется

У меня есть сервер Windows NFS и несколько серверов CentOS linux, которые устанавливают объемы из него. Сервер Windows перешел в новую сеть, и даже несмотря на то, что DNS работает, и монтирование NFS было установлено по имени хоста, похоже, что клиент NFS также отмечает значение ipaddr, которое больше недействительно. Это вызывает типичные подвесные крепления, df, проблемы, которые можно было бы ожидать. Как разрешить это ретроактивно?

  • Определите процесс, который все еще использует файл в ленивой немонтированной файловой системе
  • Сбой umount / home (ZFS) при завершении работы
  • Как автоматически принудительно использовать umount на накопителе USB, который уже удален?
  • Безопасное удаление каталога только в том случае, если оно не является точкой монтирования
  • Как монтировать контейнер Truecrypt с тайм-аутом из командной строки?
  • Почему ленивый MNT_DETACH или `umount -l` небезопасно / опасно?
  • Почему usb-drive не отображается с помощью `lsblk` после того, как он был удален из Thunar?
  • Как запустить mount / umount до / после спящего режима?
  • 2 Solutions collect form web for “Как разрешить, когда IP-адрес сервера NFS изменяется”

    Если IP-адрес изменился, вам, скорее всего, придется перезапустить NFS-клиенты и / или запустить команду umount явно освобождающую установленную службу. Возможно, это не удастся завершить, если исходная служба NFS исчезла.

    Единственным другим подходом, который я смог найти, был этот, написанный в этой статье Linux Journal под названием « How-To: Release Stuck NFS Mounts без перезагрузки» . Я никогда не использовал этот подход и до сегодняшнего дня никогда не слышал об этом методе, но это звучит выполнимо, просматривая его.

    Также я считаю, что вы можете столкнуться с проблемами в зависимости от того, монтируется ли NFS mount с помощью intr / nointr. Вы можете больше узнать об этом переключателе функций на странице руководства NFS, man nfs .

    выдержка

     intr / nointr Selects whether to allow signals to interrupt file operations on this mount point. If neither option is specified (or if nointr is specified), signals do not interrupt NFS file operations. If intr is specified, system calls return EINTR if an in-progress NFS operation is interrupted by a signal. Using the intr option is preferred to using the soft option because it is significantly less likely to result in data corruption. The intr / nointr mount option is deprecated after kernel 2.6.25. Only SIGKILL can interrupt a pending NFS operation on these kernels, and if specified, this mount option is ignored to provide backwards compatibility with older kernels. 

    У этой почты есть шаги, которые сработали для меня. В двух словах:

    • Назначьте старый IP-адрес сервера NFS псевдонимам. ifconfig eth0:fakenfs Old_IP netmask xxx.xxx.xxx.xxx
    • umount -l /mount
    • сбить псевдоним: ifconfig eth0:fakenfs down
    • Снова mount -a общий ресурс NFS: mount -a
    Linux и Unix - лучшая ОС в мире.