У нас есть машина с установленной Win7-x64. На этой машине с VirtualBox мы запускаем гостевую Fedora-x64. Мы определили общий ресурс NFS для этого экземпляра Fedora. Вот запись в / etc / exports:
/ DVR 192.168.0.0/192.168.255.255(rw)
IP-адрес компьютера с Windows - 192.168.1.100, IP-адрес гостевой системы Fedora - 192.168.1.110. Сетевой режим виртуальной машины настроен на мостовую сеть.
Теперь из другого окна Linux, когда мы пингуем гостя Fedora (192.168.1.110), мы получаем ответы нормально. Однако, когда мы пытаемся смонтировать общий ресурс nfs, мы получаем ошибку «нет маршрута к хосту». Мы используем следующую команду:
монтировать -t nfs 192.168.1.110:/dvr / mnt / test
Чтобы убедиться в отсутствии проблем с iptables, в гостевой системе Fedora мы сделали:
остановка службы iptables
и снова попытался смонтировать, но безуспешно.
Есть идеи, что может быть не так в нашей настройке? Все эти машины связаны друг с другом через концентратор. Маршрутизатор Linksys настроен как DHCP-сервер, с которого все машины получают IP-адрес.
Спасибо.
Я знаю, что этот вопрос немного устарел, но я думаю, что он все еще актуален. Настройка монтирования NFS может быть сложной задачей, поскольку она состоит из нескольких компонентов, поэтому в брандмауэре необходимо открыть более одного порта. Кроме того, Fedora использует firewalld, поэтому нет службы под названием «iptables».
Я предполагаю, что ваш экспорт правильно определен на сервере NFS (Документация TLDP), который является еще одним ящиком Fedora. Не забывай бежать exportfs -ra после редактирования /etc/exports. С таким же успехом это может быть ваш виртуальный компьютер, на котором запущен VirtualBox (для настройки общего файлового ресурса между хостом и гостем без необходимости устанавливать и поддерживать пакет гостевых дополнений), это не имеет значения.
Пытаясь смонтировать общий ресурс NFS на вашем «клиенте», вы можете столкнуться с таймаутом:
# mount -v Share/
mount.nfs: timeout set for Tue May 22 15:40:52 2018
mount.nfs: trying text-based options 'vers=3,addr=192.168.56.1'
mount.nfs: prog 100003, trying vers=3, prot=6
^C
RPC должен работать (должен иметь возможность общаться), чтобы NFS работала. В этом случае он не может подключиться к серверу NFS (192.168.56.1 - это IP-адрес по умолчанию хост-системы VirtualBox, замените его IP-адресом вашего NFS-сервера):
# rpcinfo -p 192.168.56.1
rpcinfo: can't contact portmapper: RPC: Remote system error - No route to host
Чтобы брандмауэр не блокировал NFS на сервере (хосте виртуальной машины или отдельном сервере), вы не должны отключать его, что позволяет все. Вам необходимо определить сетевой интерфейс, через который подключается клиент. Если он не назначен зоне межсетевого экрана, выберите подходящую (возможно, не «общедоступную»). Затем разрешите NFS в этой зоне.
Определите сетевой интерфейс (на сервере должны быть запущены следующие команды):
# ip address
...
6: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 192.168.56.1/24 brd 192.168.56.255 scope global vboxnet0
valid_lft forever preferred_lft forever
В этом примере клиент подключается к 192.168.56.1, поэтому vboxnet0 правильный интерфейс на этом хосте.
Определите зону межсетевого экрана, к которой назначен этот интерфейс.
# firewall-cmd --get-zone-of-interface vboxnet0
Если это «не зона», вам нужно выбрать одну и назначить ее самостоятельно. Например, «внутренний», чтобы было очевидно, что NFS нельзя использовать на внешних интерфейсах.
# firewall-cmd --add-interface=vboxnet0 --zone=internal
Если вы сейчас перечислите все интерфейсы во «внутренней» зоне, должно появиться «vboxnet0»:
# firewall-cmd --list-interfaces --zone=internal
vboxnet0
Включите те «службы» (т. Е. Откройте порты), которые требуются серверу NFS.
# firewall-cmd --add-service nfs --zone internal
# firewall-cmd --add-service mountd --zone internal
# firewall-cmd --add-service rpc-bind --zone internal
Еще раз проверьте, включены ли эти службы для сетевых устройств во «внутренней» зоне:
# firewall-cmd --list-services --zone internal
ssh mdns samba-client dhcpv6-client nfs ntp mountd rpc-bind
Если этот брандмауэр на сервере блокировал NFS, теперь он должен работать. Или, может быть, нет, потому что у вас есть другой брандмауэр в сети. Однако речь идет о Fedora и ее firewalld.
И последнее, но не менее важное: все изменения, внесенные перечисленными выше командами, являются временными. Изменилась только конфигурация времени выполнения (поскольку --permanent не использовался). Если вы допустили ошибку, все ваши изменения исчезнут после перезапуска firewalld.
Если вы хотите сохранить свои изменения, вам необходимо сохранить их в постоянной конфигурации (документация firewalld):
# firewall-cmd --runtime-to-permanent
Сейчас Fedora использует firewalld в качестве межсетевого экрана. Непосредственная остановка iptables - неправильный способ остановить брандмауэр. Пытаться systemctl stop firewalld.service вместо.
Вы запустили службу NFS на виртуальной машине Fedora, не так ли?
Вы бы сделали это, запустив systemctl start nfs.service на ВМ.
Если вы изменили /etc/exports файл с момента запуска nfsd, то вам нужно либо systemctl restart nfs.service или реэкспортируйте файловые системы с exportfs -a команда.
/etc/exports ожидает IP-адрес, за которым может следовать CIDR или сетевая маска старого стиля.
Поэтому вам нужно изменить его на один из:
/dvr 192.168.0.0/255.255.0.0(rw)
или:
/dvr 192.168.0.0/16(rw)
(Также можно использовать имена хостов, но здесь это не имеет значения.)