Общие сетевые диски NFS в UNAS.

Общие сетевые диски NFS в UNAS., UniFi Drive

dsfuchs

Guest

12.11.2024 15:28:00

У кого-нибудь получилось настроить и использовать один или несколько NFS-шар в Drive (UNAS)? У меня не получилось. Я следовал «инструкциям». Drive показывает, что шара доступна, но любое внешнее устройство, на которое я пытался смонтировать NFS-шару, выдаёт ошибку "create storage failed: mount error: mount.nfs: access denied by server while mounting 192.168.7.119:/var/nfs/shared/itero". Я получаю это идентичное сообщение об ошибке на каждом внешнем устройстве, на котором я пытался смонтировать NFS-шару в Drive (UNAS). (И Ubuntu, и Debian, macOS и TrueNAS Scale). У кого-нибудь вообще получилось работать с NFS-шарами? Может, что-то ускользает от моего внимания? (Я открыл 'тикет' в Unifi и жду ответа.) Спасибо.

melvinf22 Guest	#2 29.06.2025 03:28:00 Странно, у меня на Ubuntu сервере такие параметры, а fstab не монтирует, когда я его сохраняю. Приходится sudo mount -a использовать, чтобы заставить его сработать, а после перезагрузки всё опять исчезает.

generious

Guest

19.05.2025 14:19:00

Недавно обновление NAS сломало мое NFS-соединение на всех трех серверах. Раньше я должен был указывать пользователю vers=3 для NFS версии 3, а теперь это больше не требуется, убрал и все заработало снова.

Для fstab: 192.168.1.5:/var/nfs/shared/DockerDownloader /mnt/Downloader nfs rw,relatime,nolock

generious

Guest

04.05.2025 16:55:00

Получил свой работающий на CentOS. Вот моя запись в fstab:
192.168.1.5:/var/nfs/shared/NFS /mnt/nfs/nas nfs rw,relatime,vers=3,nolock

На NAS создал общий доступ под названием NFS.
Зашёл в services ==> NFS
Добавил NFS-соединение
Выбрал NFS
И в разделе IP указал IP-адреса моих серверов Rocky Linux и CentOS.
Обновил fstab, затем просто выполнил mount -a.
Всё работает отлично.

Кстати, если монтируешь на ESXi, выбирай версию NFS 3, так как этот NAS, похоже, не работает с NFS версией 4.

richardscholtens

Guest

21.04.2025 09:55:00

Спасибо за твой совет, woutceu! Это решило мою проблему. Теперь всё работает полностью. Я выложил все свои ресурсы Kubernetes в публичный репозиторий GitHub, чтобы все могли использовать это. Смотрите ресурсы Kubernetes и инструкции: https://github.com/richardscholtens/unas-pro-kubernetes-nfs-provisioner/tree/main

MFPN Guest	#6 09.04.2025 08:18:00 Я тоже использую UNAS с драйвером nfs-csi в Kubernetes. Сейчас (экспериментально) я добавляю это в свои манифесты: securityContext: fsGroup: 988 Exports:rw,sync,no_subtree_check,crossmnt,all_squash,anonuid=977,anongid=988

mekkmekk Guest	#7 31.03.2025 23:31:00 Слежу за этой темой, потому что у меня те же ограничения с неподпривилегированными контейнерами LXC с Docker.

woutceu

Guest

16.03.2025 18:52:00

Я, к своему удивлению, в целом добился работы сразу "из коробки". С двумя важными аргументами при монтировании: "-o nfsvers=3 nolock". "nfsvers=3" оказался необходим, чтобы избежать ошибки "No such file or directory". А "nolock" пригодился просто для того, чтобы всё заработало в принципе (я как раз использую подобный вариант с StorageClass и NFS). Теперь у меня есть рабочие StorageClass и PVC с UNAS Pro

adamscybot

Guest

04.03.2025 20:42:00

Я разрабатываю инструмент, который, среди прочего, позволяет изменять настройки squash на уровне каждого диска и даже не перезаписывать их при изменении настроек NFS в UI UniFi Drive. Основная часть уже есть, нужно ещё пара недель. Будет опубликован как open source на GitHub.

tylerlucas

Guest

#10

28.02.2025 02:33:00

Это ограничение связано с текущими опциями конфигурации NFS на UNAS Pro. Похоже, применены опции экспорта root_squash и all_squash, и удаленные пользователи перемапятся к 977:988. Учитывая это:

Изменять права на уровне Unix на UNAS Pro не имеет смысла, так как входящие NFS-соединения перемапятся.
Создавать новых пользователей на уровне Unix на UNAS Pro тоже не имеет смысла, по той же причине.

Мой подход:
Оставлять права по умолчанию.
Для Docker-сервисов, которые хотят изменить владельца файлов ('chown') или проверять права, убедитесь, что эти контейнеры запускаются с uid:gid 977:988.

Надеюсь, в будущем NFS будет расширена, чтобы предоставить более современные опции конфигурации. Текущая реализация NFS на UNAS Pro выглядит сырой и, на мой взгляд, вполне неприемлемой для продукта, который называет себя NAS.

obiwantoby

Guest

#11

21.02.2025 04:10:00

Вижу много таких ошибок. 2025-02-20T23:02:47-05:00 TheOneRing rpc.mountd[4038]: Не удается экспортировать /, возможно, не поддерживаемая файловая система или требуется fsid=. Не удается экспортировать /, возможно, не поддерживаемая файловая система или требуется fsid=.

xvilo Guest	#12 17.02.2025 20:02:00 Хочу добавить, что когда я пытаюсь смонтировать это в WSL2 (Debian), на Windows 11 через `sudo mount -t nfs -o vers=4 172.16.0.234:/var/nfs/shared/[name] /mnt/[name]`, я вижу ту же ошибку.

xvilo

Guest

#13

09.02.2025 08:58:00

Пытаюсь использовать функционал NFS для моего локального Kubernetes кластера дома в качестве CSI-драйвера. Установил и настроил CSI-драйвер для работы с NAS. Создал отдельный диск в интерфейсе UNAS и добавил NFS-конфигурацию через UI, IP-адрес, который я использовал, — это IP-адрес узла моего Kubernetes кластера, и я выбрал диск. Когда теперь создаю PVC, это не работает, и при описании получаю следующее: `Output: mount.nfs: mounting 172.16.0.234:/var/nfs/shared/kubernetes failed, reason given by server: No such file or directory` Где `172.16.0.234` — это IP-адрес UNAS, а `kubernetes` — имя диска. Так что я немного в замешательстве, почему говорит «No such file or directory». А `/var/nfs/shared` — это правильно?

trickiegt

Guest

#14

31.01.2025 19:52:00

Только что получил свой UNAS. Возникли проблемы при настройке NFS-монтажа на привилегированный Proxmox LXC. Пришлось редактировать /etc/pve/lxc/container.conf. Добавил это в конфигурацию контейнера Proxmox, и теперь монтирую внутри контейнера без проблем.

lxc.apparmor.profile = unconfined
lxc.cgroup.devices.allow = c 10:229 rwm
lxc.mount.auto = proc:rw sys:rw cgroup:rw
lxc.apparmor.allow_nesting = 1

jsdavenport

Guest

#15

17.01.2025 19:08:00

Настоятельно рекомендую не использовать NFS. Несколько дней назад я переносил данные через NFS на свой UNAS, коробка вышла из строя и больше не загружалась. Пришлось сбросить ее к заводским настройкам, к счастью, ничего не потерял, но поддержки от Ubiquiti не получил никакой — тикет просто пролежал пару дней. В общем, коробку удалось вернуть в строй сегодня днем, и данные оказались на месте, так что хорошие новости. Но как только я снова включил NFS и начал загружать общие папки, устройство снова вышло из строя. Если попытаться зайти на него через браузер, будет ошибка 403 Forbidden, а если через портал, то страница просто циклически перезагружается и никогда не загружается. Похоже, UNAS сейчас очень даже бета-версия.

RayBishopTN Guest	#16 17.01.2025 17:26:00 Да, кто-нибудь уже разобрался с этим? У меня та же проблема, и я хочу подключить это через NFS. @fizpop Ты вносил какие-нибудь изменения в экспорт?

Branks Guest	#17 08.01.2025 16:45:00 Ты смог заставить это работать? У меня вчера только UNAS Pro появился, и я бы хотел настроить NFS на Raspberry Pi. Похоже, монтирование тома и передача его в Docker контейнер приводят только к ошибкам разрешений.

rachez Guest	#18 21.12.2024 14:26:00 @bbpeabody, у меня та же проблема, решение от fizpop здесь тоже не работает. При спуске в смонтированный NFS-шар я получаю ошибку "permission denied", хотя на клиенте и сервере используется nfsusr с одинаковыми uid и gid. Использовал предложенный метод монтирования из документации Unifi: mount -t nfs <ip>:/var/nfs/shared/files1 /mnt/unaspro/files1/ https://help.ui.com/hc/en-us/articles/26277250895895-UniFi-Drive-Access-Your-UniFi-Drive-from-Linux-Desktop-Using-NFSDid. Получил какой-нибудь ответ по твоему тикету в Unifi, или решил проблему с NFS-шарой?

Читают тему (гостей: 1)