Greetings,

It's me again with another tyro problem.

I'm trying to set up my big Ryzen M9 workstation as compute host for my
desktop PC, which is an i5 NUCI. I had the same arrangement working well with the i5's predecessor, but I can't make it work this time.

The idea is to NFS-export the i5's portage and packages directories to the M9, which mounts it in a chroot partition to work on it. The M9 is on the wored LAN, the i5 uses WiFi to connect through the ADSL modem-router. The M9 has a separate partition for the chroot, but the i5 portage tree and packages directory both live under the /var partition.

I've used the same script and file-system layout on the M9 as before, merely adjusting the IP address.

# mount /mnt/nuci
# mount -t nfs 192.168.178.40:/mnt/nfs/portage /mnt/nuci/var/db/repos/gentoo mount.nfs: mounting 192.168.178.40:/mnt/nfs/portage failed, reason given by server: No such file or directory

That reply comes about 15s after the mount command, so DNS is working and traffic is flowing between the machines.

This is /etc/exports on the i5:

/mnt/nfs \
192.168.178.7(rw,sync,no_subtree_check,anonuid=250,anongid=250,crossmnt,fsid=0)
/mnt/nfs/portage \
192.168.178.7(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=250,anongid=250)
/mnt/nfs/portage.packages \
192.168.178.7(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=250,anongid=250)

$ ls -la /mnt/nfs/portage | head
total 1.1M
drwxr-xr-x 179 root portage 4.0K Sep 20 10:27 .
drwxr-xr-x 4 root root 4.0K Oct 8 14:21 ..
drwxr-xr-x 451 portage portage 12K Sep 5 15:51 acct-group
drwxr-xr-x 421 portage portage 12K Sep 5 15:51 acct-user
drwxr-xr-x 27 portage portage 4.0K Sep 3 14:36 app-accessibility
drwxr-xr-x 194 portage portage 4.0K Oct 1 12:13 app-admin
drwxr-xr-x 12 portage portage 4.0K Sep 3 14:36 app-alternatives
drwxr-xr-x 6 portage portage 4.0K Sep 3 14:36 app-antivirus
drwxr-xr-x 111 portage portage 4.0K Sep 3 14:36 app-arch

Everything under /mnt/nfs/portage has owner portage:portage. (I found that necessary on the earlier setup, so it's the same here.)

I've checked the firewall settings and logs; no problems found. Both kernels have NFSv3 and v4, but not 4.1 or 4.2. What else can I check?

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday 17 October 2024 16:00:36 GMT I wrote:

8

Well, it looks as though I have it working, over an Ethernet link anyway. There's now no /mnt/nfs with fsid=0, with the portage tree and the packages directory mounted below it. This is /etc/exports on the i5:

/var/db/repos/gentoo wstn.prhnet(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=250,anongid=250)
/var/cache/packages wstn.prhnet(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=250,anongid=250)

Those are just two long lines. Breaking them seemed to cause problems. You see that there's no intermediate mount point.

The last two weeks' work has left me unsure of the integrity of the i5, so I'm going to install a fresh new system and save it before tackling the wireless link. Then I may be able to coil up that great long Ethernet cable and stow
it.

Many thanks to all those who offered help.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wednesday 30 October 2024 23:24:19 GMT Peter Humphrey wrote:

On Thursday 17 October 2024 16:00:36 GMT I wrote:

8

Well, it looks as though I have it working, over an Ethernet link anyway. There's now no /mnt/nfs with fsid=0, with the portage tree and the packages directory mounted below it. This is /etc/exports on the i5:

/var/db/repos/gentoo wstn.prhnet(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=250 ,anongid=250)
/var/cache/packages wstn.prhnet(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=250 ,anongid=250)

Those are just two long lines. Breaking them seemed to cause problems. You see that there's no intermediate mount point.

Yes, the /etc/exports syntax is sensitive to breaks or spaces. There should
be a single space between the exported directory and the client's hostname or IP address and no more.

The last two weeks' work has left me unsure of the integrity of the i5, so I'm going to install a fresh new system and save it before tackling the wireless link. Then I may be able to coil up that great long Ethernet cable and stow it.

Hmm ... if your NFS configuration works over wired ethernet, but not over wireless, this could point to a lower network level problem.

I tend to use static IP addresses on both endpoints to simplify checks and configuration, but if you use hostnames check reverse name resolution is correct and adjust your /etc/hosts on both ends, check the DNS configuration
on your LAN and check the client/server IP allocations are as they should be.

Temporarily disable firewalls on both ends and check connectivity and access
to NFS ports 111,2049 on the server.

Check firewall logs/rules on the wireless router and configure accordingly if they are blocking.

Finally, make sure hostnames/IP addresses are correctly reflected on NFS configuration at both ends.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmcjU1cACgkQseqq9sKV ZxnFdRAAmrKgeeOgZiMDAmwkpevUMpfJ5IfUr/2fHs2Cb5FP5DwdmHu8TA4FVOoT qRx2DFd+1i82Fln76a7z1geAwga3rbUZ0Yz3jTX2FsMkZjC4gX1+wX1Yu4O9vzYz ZOjL/9C0p1BC7Ublj8HuFmR5LjD1fpcllOk9fYaQnWtXMa3vYgZSUyblAQM2ESaY L10VYjJ0vSO2rH43AskxNkjok6Nx8RR8WLTspV6jbSK50oxKXYrjXElBadE3P5gI +b+/CXyKd9Ood+syEzbBFd8cB7YcMEjbei+40UwTKHzu1T+hs5aarO0o/frGY2Bp xzBVIg7sEOMl/1p88qMKn9OrQNyhXv8bHoFMYgCiJzKbLPi3RYQhjNNB1GrAgLFa nGkspsI5AGX1pwB2SHYanr8CLKSnbahDMqVpJsngswNk8ACM7Dq8GznYVj5Atnf0 k/AdXzrvY3F/PjCDRBha2Fe7IywthySvlaFNeAFhemsjd03lY4Jxn2h9xWpmaxD/ DpXw4bCWyA8r9Ja75CUf5HDsKXdO+mw8KiYRN6LcG6VdZ3kwf0GeNNc7rphvF0gy IHvz5sIitVPL9gIJ1BC6nA1M89k9HCBQOaArF/qKruOihD6nqBtz1a4KaQwaiJh4 QG2LtMGZP9v6OBEmYPdfhAqk4aubVkMmihUa8lqcDk+4evGqnrk=
=y5l+
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday 31 October 2024 09:52:23 GMT Michael wrote:

On Wednesday 30 October 2024 23:24:19 GMT Peter Humphrey wrote:

On Thursday 17 October 2024 16:00:36 GMT I wrote:

8

Well, it looks as though I have it working, over an Ethernet link anyway. There's now no /mnt/nfs with fsid=0, with the portage tree and the
packages directory mounted below it. This is /etc/exports on the i5:

/var/db/repos/gentoo wstn.prhnet(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=25 0 ,anongid=250)
/var/cache/packages wstn.prhnet(rw,sync,insecure,nohide,no_subtree_check,all_squash,anonuid=25 0 ,anongid=250)

Those are just two long lines. Breaking them seemed to cause problems. You see that there's no intermediate mount point.

Yes, the /etc/exports syntax is sensitive to breaks or spaces. There should be a single space between the exported directory and the client's hostname
or IP address and no more.

I can only say that a backslash used to work, but now it doesn't.

The last two weeks' work has left me unsure of the integrity of the i5, so I'm going to install a fresh new system and save it before tackling the wireless link. Then I may be able to coil up that great long Ethernet
cable and stow it.

Hmm ... if your NFS configuration works over wired Ethernet, but not over wireless, this could point to a lower network level problem.

I remember you said something about problems with some DSL routers. Let's wait and see though. I won't be ready to try it today.

I tend to use static IP addresses on both endpoints to simplify checks and configuration, but if you use hostnames check reverse name resolution is correct and adjust your /etc/hosts on both ends, check the DNS configuration on your LAN and check the client/server IP allocations are as they should
be.

I've always used static addresses. The exception is the wireless network, on which things come and go. I'm confident in dnsmasq on the wired LAN - it's been running for years.

Temporarily disable firewalls on both ends and check connectivity and access to NFS ports 111,2049 on the server.

The firewalls are fine. They're the first thing I check in a case like this.

Check firewall logs/rules on the wireless router and configure accordingly
if they are blocking.

The shorewall NFS macro allows TCP ports 111, 2049 and 20048; that last one is for mountd. The router is a Fritz!Box, and it's a bit of a beast to
understand. (Is there a characteristic German approach to user interface design? I begin to wonder, what with this and my boiler...)

Finally, make sure hostnames/IP addresses are correctly reflected on NFS configuration at both ends.

Of course.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday 31 October 2024 11:07:13 GMT Peter Humphrey wrote:

On Thursday 31 October 2024 09:52:23 GMT Michael wrote:

Hmm ... if your NFS configuration works over wired Ethernet, but not over wireless, this could point to a lower network level problem.

I remember you said something about problems with some DSL routers. Let's wait and see though. I won't be ready to try it today.

I had mentioned it, in the context of using the 'secure' option in /etc/ exports, which expect requests to originate from privileged service ports
lower than 1024. Some wireless router firewall implementations block these ports between clients. In addition, if the WiFi 'Wireless Client Isolation' feature enabled devices are not allowed to communicate with each other
(blocked at Layer 2). They have to route everything through the gateway and VLAN or other address space isolation/routing is applied there.

I tend to use static IP addresses on both endpoints to simplify checks and configuration, but if you use hostnames check reverse name resolution is correct and adjust your /etc/hosts on both ends, check the DNS configuration on your LAN and check the client/server IP allocations are
as they should be.

I've always used static addresses. The exception is the wireless network, on which things come and go. I'm confident in dnsmasq on the wired LAN - it's been running for years.

Is dnsmasq also used by the wireless network successfully, or is the router running its own DHCP/DNS show?

Temporarily disable firewalls on both ends and check connectivity and access to NFS ports 111,2049 on the server.

The firewalls are fine. They're the first thing I check in a case like this.

Check firewall logs/rules on the wireless router and configure accordingly if they are blocking.

The shorewall NFS macro allows TCP ports 111, 2049 and 20048; that last one is for mountd.

I think for NFSv4 only TCP port 2049 is needed, but for NFSv3 it'll need 111,2049 plus more dynamically allocated ports - I'm not entirely sure.

The router is a Fritz!Box, and it's a bit of a beast to
understand. (Is there a characteristic German approach to user interface design? I begin to wonder, what with this and my boiler...)

Fritz!Box is one of the better provisioned domestic routers. I've only used
it once and mostly over wired ethernet, but was impressed by its functions and features compared to other rubbish on the market. I can't recall its firewall options menu - I would think there would be no restrictions across LAN
devices, bar Wireless Client Isolation. Different VLANs would either way isolate wireless devices to their own broadcast domain. For a quick test you can disable wireless client isolation and see if things start working as expected.

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEXqhvaVh2ERicA8Ceseqq9sKVZxkFAmcjkmcACgkQseqq9sKV ZxmCaA/9HNuHNj3iuixSGuK+Ime0S/SKC1e3sUMQQeOKCO4P4vGf6SY8S++Ic589 u7zrXEdAtQpb3cnFzyq52539wwJbppxwN/ic3VKQ9IFp+GuQD1ftVhpN+seNQKoe uEEFxlwPpN4loQKNn3hmWduK37LEbVALLejpAJOhMtJ+tCn9/lBzn1Qp4sjkvUX8 pZPfrj8itr1ZwXTSAidquIyVXLy+VIS0OkGlSECJTM7KgjzyiI5wiONrLa1wNVqU 0X6OcJKKvvbG+EQAFj+7HWF3eyh2Q+CfvRZlKjyFOvsK/F3Tr7UT6AJF4zarK/49 jGFpbC8tRy5KgQi5AtrnQRLM4nhmXPsXztugUxDz9lJwdGji2SLC6ISyhTmSPuD2 jJeEvZPJzIMiS9OPeMo7FPvhv0YEI/Ew5mVpduwR7puqr/Q2UTU31lyRWkJSF/UC IjYkANj9/+1Iv1qg+Y7RLm/VDDhepyLpNXeLixpq8g4MwGgH1YN7C48clvBNN2vG aPVUrcB3hvXGCgme53xk6LOXXJ/fi+0cI1Du5aErb058xBNIekeYWDVBBMm/JJmT H8VHsAECZBogResDLoK2YkZVD7ogQuE16yjnLW8EL2JftAnEJ+cvKaR+GOV0oHSn O+V/p3GKC7hr8Gk/uTRn+GIk/rPuOzoe6O1FWjm7HzWjC/WQjh0=
=B/vB
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thursday 31 October 2024 14:21:27 GMT Michael wrote:

On Thursday 31 October 2024 11:07:13 GMT Peter Humphrey wrote:

I've always used static addresses. The exception is the wireless network, on which things come and go. I'm confident in dnsmasq on the wired LAN - it's been running for years.

Is dnsmasq also used by the wireless network successfully, or is the router running its own DHCP/DNS show?

I meant to say: dnsmasq serves the wired network; the router serves DHCP to
the wireless one, since it's directly upstream of them and dnsmasq isn't.

8

The router is a Fritz!Box, and it's a bit of a beast to understand. (Is there a characteristic German approach to user interface design? I begin
to wonder, what with this and my boiler...)

Fritz!Box is one of the better provisioned domestic routers.

That'll be why Zen Internet uses it then. That's my ISP, as you can tell from my address.

I've only used it once and mostly over wired Ethernet, but was impressed by its functions and features compared to other rubbish on the market. I can't recall its firewall options menu - I would think there would be no restrictions across LAN devices, bar Wireless Client Isolation. Different VLANs would either way isolate wireless devices to their own broadcast domain. For a quick test you can disable wireless client isolation and see
if things start working as expected.

I've just tried to find its firewall setup, and failed. Searching for 'firewall'
in the manual finds nothing. I'll keep looking.

--
Regards,
Peter.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)