[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

[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

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.