На данный момент эта проблема сводит меня с ума. У меня есть сервер NFS Ubuntu 16.04, который отлично работал с этой конфигурацией:
/etc/fstab:
UUID=b6bd34a3-f5af-4463-a515-be0b0b583f98 /data2 xfs rw,relatime 0 0
/data2 /srv/nfs/cryodata none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
и
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Все это работало нормально в течение нескольких месяцев на одном клиенте nfs, использующем эту конфигурацию, до сих пор с использованием следующих записей / etc / fstab на стороне клиента:
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
Однако, поскольку это очень большой сервер хранения, было решено, что на нем необходимо разместить несколько лабораторий. Итак, я переместил все, что было разбросано по разделу / data2, в подкаталог / data2 / cryodata и обновил / etc / fstab на сервере и / etc / exports следующим образом:
/etc/fstab:
...
/data2/cryodata /srv/nfs/cryodata none defaults,bind 0 0
/data2/xray /srv/nfs/xray none defaults,bind 0 0
/data2/EM /srv/nfs/EM none defaults,bind 0 0
/usr/local /srv/nfs/local none defaults,bind 0 0
и
/etc/exports
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/EM 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/xray 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Это просто не работает! Когда я пытаюсь смонтировать новое монтирование на клиенте, используя ту же запись client / etc / fstab:
{nfs client} /etc/fstab:
...
kraken.bio.univ.edu:/local /usr/local nfs4 _netdev,auto 0 0
kraken.bio.univ.edu:/cryodata /cryodata nfs4 _netdev,auto 0 0
.
# mount -v /cryodata
mount.nfs4: timeout set for Sat Feb 24 09:24:38 2018
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=192.168.41.171,clientaddr=192.168.159.31'
mount.nfs4: mount(2): Stale file handle
mount.nfs4: trying text-based options 'addr=128.83.41.171,clientaddr=129.116.159.31'
...
/ Usr / local продолжает монтироваться без проблем. В первый раз, когда я попробовал это, я забыл экспортировать / экспортировать файловые системы, используя exportfs -var перед внесением изменений, но с тех пор я переключаюсь взад и вперед, стараясь не экспортировать и размонтировать все, с несколькими перезагрузками сервера между ними. Первоначальное монтирование привязки всего раздела всегда работает, а монтирование подкаталога с привязкой каждый раз завершается ошибкой с сообщением устаревшего дескриптора nfs. Я попытался включить другие клиенты nfs, которые никогда не монтировали эти разделы, и получил точно такое же сообщение об ошибке: в этом случае это определенно проблема на стороне сервера. Я проверил / var / lib / nfs / etab, чтобы убедиться, что он очищен между попытками монтирования и т. Д.
Я думал, что техника привязки к корневому каталогу сервера nfs решает все эти проблемы, но, видимо, нет? Странно то, что / usr / local - это подкаталог другого раздела, и он всегда монтируется нормально. Он находится на ext3 md raid 1, хотя я не могу себе представить, что это имеет значение.
Я потратил на это несколько часов и почти сломал Google в поисках решения безрезультатно.
Обратите внимание, что я экспортирую только файловые системы, смонтированные на привязке. Этот раздел из экспорт страница руководства актуальна:
fsid = число | корень | uuid
NFS должна иметь возможность идентифицировать каждую экспортируемую файловую систему. Обычно он будет использовать UUID для файловой системы (если в файловой системе есть такая вещь) или номер устройства, на котором находится файловая система (если файловая система хранится на устройстве).
Мое ошибочное предположение заключалось в том, что привязанные файловые системы имеют какой-то UUID, который NFS может использовать автоматически; и предположение, подкрепленное тем фактом, что оба этих экспорта, подключенных к привязке, нормально работали без fsid:
/srv/nfs 192.168.159.31(rw,sync,fsid=0,crossmnt,no_subtree_check)
/srv/nfs/cryodata 192.168.159.31(rw,sync,no_subtree_check)
/srv/nfs/local 192.168.159.31(rw,sync,no_subtree_check)
Однако это приводит к непоследовательному поведению. Я добавил привязку смонтированную / opt:
/etc/fstab:
/data1/opt /srv/nfs/opt none defaults,bind 0 0
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,no_subtree_check)
привело к непоследовательному поведению; т.е. может изменить экспортный IP-адрес и смонтировать на одном компьютере, но получить разрешение на другом отказано. Решением было добавить fsid:
/etc/exports:
/srv/nfs/opt 192.168.159.3(rw,sync,fsid=20,no_subtree_check)
Таким образом, решение состоит в том, чтобы всегда добавлять fsid для экспорта файловых систем, подключенных к привязке.