Укороченная версия: установленные наборы данных - это RO, хотя я пытаюсь сделать их RW.
Длинная версия: в настоящее время у нас есть рабочая реализация ZFS на Linux на Wheezy (которую я унаследовал, когда ушел предыдущий SE), и мы хотим перейти на Jessie ... потому что ... просто потому, что. Перед обновлением производственной среды я пытаюсь воспроизвести эту среду (насколько это возможно) на виртуальной машине, работающей на моем локальном компьютере.
Я создал пул и создал новый набор данных с помощью:
root@zfstest1:~# zfs set sharenfs=rw=@10.1.2.3,insecure tank/vmware
root@zfstest1:~# zfs share -a
root@zfstest1:~# showmount -e
Export list for zfstest1:
/tank/vmware 10.1.2.3
Я сравнил разрешения, свойства и все, что я могу придумать, с производством, но независимо от того, монтирую ли я наборы данных на моем Mac или на хосте VMware, том / хранилище данных в конечном итоге становится RO. Разрешения по умолчанию для / tank и дочерних объектов кажутся равными 755, и единственный способ, который я нашел, сделать подключенные тома на моем Mac или хосте VMware RW, - это сделать их 777.
Некоторые вещи, которые я знаю, отличаются - это разные пакеты zfs-debian, spl-dkms и т. Д. Мне просто не удалось найти репозиторий, чтобы получить старые (0.6.3-1 ~ wheezy против 0.6.5.2-2-wheezy)
Буду очень признателен за помощь в том, что я могу найти, чтобы заставить эту работу работать.
sharenfs будет казаться неудачным, если zfs набор данных не имеет mountpoint устанавливать
Итак, я обнаружил, что работает
root@zfstest1:~# exportfs -v
дает мне другой результат на моей тестовой виртуальной машине, чем на моем производственном сервере. мне не хватает того, что / etc / exports по умолчанию для обоих, а результаты
root@zfstest1:~# zfs get sharenfs
такие же, но / var / lib / nfs / etab файл на производстве явно содержит записи откуда-то ... Я просто не знаю откуда и как.
В конечном итоге разница в том, что файл etab имеет no_root_squash в этом.
Итак, я полагаю, что эту актуальную проблему можно считать решенной, но теперь мне нужно выяснить другую проблему: где / var / lib / nfs / etab получает эту информацию и почему наш производственный сервер заполняет ее именно так.
ОБНОВИТЬ: Так что exportfs -v команда получает информацию от zfs share -a или zfs share [dataset] команда. Делая service nfs-kernel-server restart стирает, или, по крайней мере, работает showmount -e или exportfs -v после перезапуска этой службы ничего не показывает. После выполнения команды share etab повторно заполняется записями sharenfs.
... вздох ... постоянно учусь.