[gentoo-user] NFS mounting

[gentoo-user] NFS mounting

[Peter Humphrey]

Greetings,

Let me try this again.

Why should an NFS server wait 15 seconds before reporting "No such file or 
directory"?

-- 
Regards,
Peter.

Re: [gentoo-user] NFS mounting

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

On Friday 18 October 2024 14:41:03 BST Peter Humphrey wrote:
> Greetings,
> 
> Let me try this again.
> 
> Why should an NFS server wait 15 seconds before reporting "No such file or
> directory"?

I couldn't find anything conspicuously wrong in your setup, but I don't have 
much in depth experience working with NFS.  A 15 second delay seems excessive 
to me.  Even with resource constrained servers and powered down disks I don't 
see more than 5 seconds delay here.

Whenever I had an error like yours, I traced it down to some typo, gratuitous 
use of space in the syntax, or some omission in my /etc/exports file.  As I 
was reading your post I thought you could have missed using 'mount --bind' for 
your /mnt/nfs/portage to /var/ on i5, but you posted you are able to list your 
portage tree files within it.  So this is not the cause of the problem.

Differences I noticed compared to my typical setup are:

1. I define a subnet, in addition to the single client's IP address - e.g. 
192.168.178.7/255.255.255.254.
2. I do not use 'nohide'. In your case you mount each directory explicitly and 
they are probably both on the same partition/fs(?), so what purpose does 
nohide serve?
3. Will all requests come from sub-1024 port numbers, or will some strict/
obscure firewalling cause problems since you specify 'secure'?  Some domestic 
routers try to be too clever by half in this respect.  Try setting your 
exports with 'insecure' to see if it makes any difference.

Whenever you change any settings in your exports file remember to run:

exportfs -rav

You could try tweaking the above options in case it makes a difference.  
However, if the *same* settings worked with a previous client, then I can't 
logically explain why they fail now.  :-/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] NFS mounting

[Peter Humphrey]

On Friday 18 October 2024 15:55:19 BST Michael wrote:

--->8

> exportfs -rav

Ah! I knew about 'exportfs -r' but not the 'av'. When I added that I got this:

exportfs: duplicated export entries:
exportfs:       :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250)
exportfs:       :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250)
exporting :/mnt/nfs/portage.packages
exporting :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250)
exportfs: Failed to stat 192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250): No such file or directory
exporting :/mnt/nfs/portage
exporting :192.168.178.7(rw,sync,no_subtree_check,crossmnt,fsid=0)
exportfs: Failed to stat 192.168.178.7(rw,sync,no_subtree_check,crossmnt,fsid=0): No such file or directory

Of course there's a duplicate export entry; I'm exporting two directories to
the one machine. Well, three actually, counting the top-level one, /mnt/nfs.
But is that duplication the cause of the 'Failed to stat...'?

Do I need to set some opotions on an rpc service, or something?

-- 
Regards,
Peter.

Re: [gentoo-user] NFS mounting

[William Kenworthy]

On 21/10/24 10:12, Peter Humphrey wrote:
> On Friday 18 October 2024 15:55:19 BST Michael wrote:
>
> --->8
>
>> exportfs -rav
> Ah! I knew about 'exportfs -r' but not the 'av'. When I added that I got this:
>
> exportfs: duplicated export entries:
> exportfs:       :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250)
> exportfs:       :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250)
> exporting :/mnt/nfs/portage.packages
> exporting :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250)
> exportfs: Failed to stat 192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250): No such file or directory
> exporting :/mnt/nfs/portage
> exporting :192.168.178.7(rw,sync,no_subtree_check,crossmnt,fsid=0)
> exportfs: Failed to stat 192.168.178.7(rw,sync,no_subtree_check,crossmnt,fsid=0): No such file or directory
>
> Of course there's a duplicate export entry; I'm exporting two directories to
> the one machine. Well, three actually, counting the top-level one, /mnt/nfs.
> But is that duplication the cause of the 'Failed to stat...'?
>
> Do I need to set some opotions on an rpc service, or something?
>
Are you running a firewall - if so turn it off (on both machines) and 
test.  If that's the cause, you might have to pin the nfs ports.

BillK

Re: [gentoo-user] NFS mounting

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

On Monday 21 October 2024 03:12:23 BST Peter Humphrey wrote:
> On Friday 18 October 2024 15:55:19 BST Michael wrote:
> 
> --->8
> 
> > exportfs -rav
> 
> Ah! I knew about 'exportfs -r' but not the 'av'. When I added that I got
> this:
> 
> exportfs: duplicated export entries:
> exportfs:      
> :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,ano
> ngid=250) exportfs:      
> :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,ano
> ngid=250) exporting :/mnt/nfs/portage.packages
> exporting
> :192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,ano
> ngid=250) exportfs: Failed to stat
> 192.168.178.7(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anon
> gid=250): No such file or directory exporting :/mnt/nfs/portage
> exporting :192.168.178.7(rw,sync,no_subtree_check,crossmnt,fsid=0)
> exportfs: Failed to stat
> 192.168.178.7(rw,sync,no_subtree_check,crossmnt,fsid=0): No such file or
> directory
> 
> Of course there's a duplicate export entry; I'm exporting two directories to
> the one machine. Well, three actually, counting the top-level one,
> /mnt/nfs. But is that duplication the cause of the 'Failed to stat...'?
> 
> Do I need to set some opotions on an rpc service, or something?

Assuming all required directories are on the same fs, what happens if you 
*only* export the parent directory?  Something like this:

/mnt/nfs \ 
192.168.178.7/32(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,anongid=250)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] NFS mounting

[Peter Humphrey]

On Monday 21 October 2024 09:22:37 BST Michael wrote:

> Assuming all required directories are on the same fs, what happens if you
> *only* export the parent directory?  Something like this:
> 
> /mnt/nfs \
> 192.168.178.7/32(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,an
> ongid=250)

Actually, the converse turned out to be right. Removing the top-level /mnt/nfs 
spec from /etc/exports allowed the whole thing to spring into life.

Go figure, as they say in the colonies.  ;)

-- 
Regards,
Peter.

Re: [gentoo-user] NFS mounting

[Michael]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

On Tuesday 22 October 2024 02:10:45 BST Peter Humphrey wrote:
> On Monday 21 October 2024 09:22:37 BST Michael wrote:
> > Assuming all required directories are on the same fs, what happens if you
> > *only* export the parent directory?  Something like this:
> > 
> > /mnt/nfs \
> > 192.168.178.7/32(rw,sync,insecure,no_subtree_check,all_squash,anonuid=250,
> > an ongid=250)
> 
> Actually, the converse turned out to be right. Removing the top-level
> /mnt/nfs spec from /etc/exports allowed the whole thing to spring into
> life.
> 
> Go figure, as they say in the colonies.  ;)

I'm glad you 'figured' this, although puzzled by your solution.  In my 
experience I only needed to export one directory only as the top directory, 
for each different partition.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] NFS mounting

[Peter Humphrey]

On Tuesday 22 October 2024 10:14:48 BST Michael wrote:
> On Tuesday 22 October 2024 02:10:45 BST Peter Humphrey wrote:
> > On Monday 21 October 2024 09:22:37 BST Michael wrote:
> > > Assuming all required directories are on the same fs, what happens if
> > > you
> > > *only* export the parent directory?  Something like this:
> > > 
> > > /mnt/nfs \
> > > 192.168.178.7/32(rw,sync,insecure,no_subtree_check,all_squash,anonuid=25
> > > 0,
> > > an ongid=250)
> > 
> > Actually, the converse turned out to be right. Removing the top-level
> > /mnt/nfs spec from /etc/exports allowed the whole thing to spring into
> > life.
> > 
> > Go figure, as they say in the colonies.  ;)
> 
> I'm glad you 'figured' this, although puzzled by your solution.  In my
> experience I only needed to export one directory only as the top directory,
> for each different partition.

I followed the Gentoo NFS wiki page, which says "this article demonstrates a 
best-practice NFSv4 deployment using a virtual root".

-- 
Regards,
Peter.

Re: [gentoo-user] NFS mounting

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

On Tuesday 22 October 2024 13:00:14 BST Peter Humphrey wrote:
> On Tuesday 22 October 2024 10:14:48 BST Michael wrote:
> > On Tuesday 22 October 2024 02:10:45 BST Peter Humphrey wrote:
> > > On Monday 21 October 2024 09:22:37 BST Michael wrote:
> > > > Assuming all required directories are on the same fs, what happens if
> > > > you
> > > > *only* export the parent directory?  Something like this:
> > > > 
> > > > /mnt/nfs \
> > > > 192.168.178.7/32(rw,sync,insecure,no_subtree_check,all_squash,anonuid=
> > > > 25
> > > > 0,
> > > > an ongid=250)
> > > 
> > > Actually, the converse turned out to be right. Removing the top-level
> > > /mnt/nfs spec from /etc/exports allowed the whole thing to spring into
> > > life.
> > > 
> > > Go figure, as they say in the colonies.  ;)
> > 
> > I'm glad you 'figured' this, although puzzled by your solution.  In my
> > experience I only needed to export one directory only as the top
> > directory,
> > for each different partition.
> 
> I followed the Gentoo NFS wiki page, which says "this article demonstrates a
> best-practice NFSv4 deployment using a virtual root".

If you are referring to the NFS-utils wiki page:

https://wiki.gentoo.org/wiki/Nfs-utils

it provides an example of exporting two *different* partitions:

Device       Mount directory     Description
/dev/sdb1	   /home               Filesystem containing user home directories.
/dev/sdc1	   /data               Filesystem containing user data.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] NFS mounting

[Matt Jolly]

[-- Attachment #1: Type: text/html, Size: 2919 bytes --]

Re: [gentoo-user] NFS mounting

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2059 bytes --]

On Tuesday 22 October 2024 18:01:55 BST Matt Jolly wrote:
> It should not matter; the virtual root involves bind mounting directories
> into a single location - that could be 4 different partitions, a bunch of
> subvolumes, or some directories scattered across a single partition, or
> some combination of those options.
> 
> 
> Cheers,
> 
> 
> Matt

All good and fair, but then why Peter's reported error of duplicate exports?


> On 22 Oct 2024 23:36, Michael <confabulate@kintzios.com> wrote:
> 
> On Tuesday 22 October 2024 13:00:14 BST Peter Humphrey wrote:
> > On Tuesday 22 October 2024 10:14:48 BST Michael wrote:
> > > On Tuesday 22 October 2024 02:10:45 BST Peter Humphrey wrote:
> > > > On Monday 21 October 2024 09:22:37 BST Michael wrote:
> > > > > Assuming all required directories are on the same fs, what happens
> > > > > if
> > > > > you
> > > > > *only* export the parent directory?  Something like this:
> > > > > 
> > > > > /mnt/nfs \
> > > > > 192.168.178.7/32(rw,sync,insecure,no_subtree_check,all_squash,anonui
> > > > > d=
> > > > > 25
> > > > > 0,
> > > > > an ongid=250)
> > > > 
> > > > Actually, the converse turned out to be right. Removing the top-level
> > > > /mnt/nfs spec from /etc/exports allowed the whole thing to spring into
> > > > life.
> > > > 
> > > > Go figure, as they say in the colonies.  ;)
> > > 
> > > I'm glad you 'figured' this, although puzzled by your solution.  In my
> > > experience I only needed to export one directory only as the top
> > > directory,
> > > for each different partition.
> > 
> > I followed the Gentoo NFS wiki page, which says "this article demonstrates
> > a best-practice NFSv4 deployment using a virtual root".
> 
> If you are referring to the NFS-utils wiki page:
> 
> https://wiki.gentoo.org/wiki/Nfs-utils
> 
> it provides an example of exporting two *different* partitions:
> 
> Device       Mount directory     Description
> /dev/sdb1    /home               Filesystem containing user home
> directories. /dev/sdc1    /data               Filesystem containing user
> data.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] NFS mounting

[Peter Humphrey]

On Tuesday 22 October 2024 20:29:14 BST Michael wrote:
> On Tuesday 22 October 2024 18:01:55 BST Matt Jolly wrote:
> > It should not matter; the virtual root involves bind mounting directories
> > into a single location - that could be 4 different partitions, a bunch of
> > subvolumes, or some directories scattered across a single partition, or
> > some combination of those options.
> 
> All good and fair, but then why Peter's reported error of duplicate exports?

I don't understand that either. Well, it's just one thing actually: it looks 
as though the remote mount still isn't right, so that some transfers just seem 
to vanish down a black hole.

Now I have the NFS mounting working, apparently, with no reported errors, but 
I still can't get the combined system to behave. I mount the i5's portage tree 
and packages directory on a partition on the M9, chroot into it, 'env-update 
&& . /etc/profile' and attempt to 'emerge --sync' (this is using the Git 
method).

Everything starts to go well, and gkrellm on the i5 shows plausible network 
traffic on both machines - but no disk transfers. This goes on for a couple of 
minutes until I give up.

Before starting any of that I recovered a backup of the i5 and untarred it 
into the chroot partition; not the whole thing, just the root FS and /var, 
which I've kept separate for many years. Oh, and /usr/local. The backup was 
just two days old.

While bug-hunting, I created two new partitions on the i5: one each for the 
portage tree and the packages directory. That was to eliminate the possibility 
that the NFS mount was failing because it wasn't at a file-system root.

Also while bug-hunting, I found an extra-long Ethernet cable and strung the i5 
into the LAN that way. The M9 only ever sees the LAN, whereas I can now start 
and stop the LAN and WLAN at will on the i5. The Fritz!Box router sits at the 
junction. Eventually, of course, once I get this setup working, the cable will 
go back in the cupboard.

-- 
Regards,
Peter.

Re: [gentoo-user] NFS mounting

[Peter Humphrey]

On Tuesday 22 October 2024 22:07:06 BST I wrote:

> Also while bug-hunting, I found an extra-long Ethernet cable and strung the
> i5 into the LAN that way. The M9 only ever sees the LAN, whereas I can now
> start and stop the LAN and WLAN at will on the i5. The Fritz!Box router
> sits at the junction. Eventually, of course, once I get this setup working,
> the cable will go back in the cupboard.

I should have added that the remote compilation works well with the cable. I 
have found though that the linux-firmware ebuild requires the /boot partition 
to be mounted, which it shouldn't be on a foreign machine, so I say
emerge -uaDvN --exclude="linux-firmware-20241017-*", only to find that it's 
emerged anyway. Dropping that last hyphen gives the required result.

Is this a portage bug?

-- 
Regards,
Peter.

Re: [gentoo-user] NFS mounting

[Arve Barsnes]

On Wed, 23 Oct 2024 at 12:56, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> I should have added that the remote compilation works well with the cable. I
> have found though that the linux-firmware ebuild requires the /boot partition
> to be mounted, which it shouldn't be on a foreign machine, so I say
> emerge -uaDvN --exclude="linux-firmware-20241017-*", only to find that it's
> emerged anyway. Dropping that last hyphen gives the required result.
>
> Is this a portage bug?

It is definitely weird, but it is documented to be that way. From the
manual ebuild(5):

The version part that comes before the ’*’ must be a valid version in
the absence of the ’*’. For example, ’2’ is a valid version and ’2.’
is not. Therefore, ’2*’ is allowed and ’2.*’ is not.

Regards,
Arve

Re: [gentoo-user] NFS mounting

[Peter Humphrey]

On Wednesday 23 October 2024 12:36:23 BST Arve Barsnes wrote:
> On Wed, 23 Oct 2024 at 12:56, Peter Humphrey <peter@prh.myzen.co.uk> wrote:
> > I should have added that the remote compilation works well with the cable.
> > I have found though that the linux-firmware ebuild requires the /boot
> > partition to be mounted, which it shouldn't be on a foreign machine, so I
> > say emerge -uaDvN --exclude="linux-firmware-20241017-*", only to find
> > that it's emerged anyway. Dropping that last hyphen gives the required
> > result.
> > 
> > Is this a portage bug?
> 
> It is definitely weird, but it is documented to be that way. From the
> manual ebuild(5):
> 
> The version part that comes before the ’*’ must be a valid version in
> the absence of the ’*’. For example, ’2’ is a valid version and ’2.’
> is not. Therefore, ’2*’ is allowed and ’2.*’ is not.

Ah! Thank you Arve. The subtleties of a complex system seem endless at 
times...  :)

-- 
Regards,
Peter.

Re: [gentoo-user] NFS mounting

[Jack Ostroff]

[-- Attachment #1: Type: text/plain, Size: 287 bytes --]

On 10/18/24 9:41 AM, Peter Humphrey wrote:
> Greetings,
>
> Let me try this again.
>
> Why should an NFS server wait 15 seconds before reporting "No such file or
> directory"?
Are there any errors in the log on the server? Increasing the verbosity 
of the log there might be informative.

[-- Attachment #2: Type: text/html, Size: 653 bytes --]

[gentoo-user] Re: NFS mounting

[Grant Edwards]

On 2024-10-18, Peter Humphrey <peter@prh.myzen.co.uk> wrote:

> Why should an NFS server wait 15 seconds before reporting "No such file or 
> directory"?

I don't remember this happenning with NFS servers specifically, but
I've seen odd delays like this in other services when the server (or
client) tries to do a reverse-DNS lookup to turn the client IP address
into a hostname for logging (or whatever). You could try adding the
client name/IP address to /etc/hosts on the server and vice/versa.

--
Grant

[gentoo-user] nfs mounting

[Peter Humphrey]

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.

Re: [gentoo-user] nfs mounting

[Peter Humphrey]

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.

Re: [gentoo-user] nfs mounting

[Michael]

[-- Attachment #1: Type: text/plain, Size: 1901 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] nfs mounting

[Peter Humphrey]

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.

Re: [gentoo-user] nfs mounting

[Michael]

[-- Attachment #1: Type: text/plain, Size: 2840 bytes --]

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.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-user] nfs mounting

[Peter Humphrey]

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.