How to make nfs share accessible across subnets?

[Bo Berglund]

On Thu, 10 Feb 2022 14:48:35 -0500, Little Girl <littlergirl at gmail.com> wrote:

>Hey there,

Hi, thanks for your comments!
I have gone through them below and added my observations and tests, still no go.
I must be missing something totally vital!

>Bo Berglund wrote:
>
>>#NFS video share on ubuntuserv
>>192.168.119.216:/home/bosse/www/video /mnt/video nfs tcp,noexec,intr
>>0 0
>
>>So I looked at how nfs was set up on my Ubuntu server:
>>In the file /etc/exports I found this:
>>
>>/home/bosse/www/video 192.168.119.0/24(rw,sync,no_subtree_check)
>>/home/bosse/www/video 192.168.117.0/24(rw,sync,no_subtree_check)

This was an error by *me* in the exports file!
Both clients shall be on the *same line*.

>
>The /etc/fstab line is all about who is sharing what with me and
>where I can find it:
>
>[who is sharing with me]:[what they are sharing] [where I can find it
>on my system] [options]

Yes I know that...

>The /etc/exports line is all about what I am sharing and with whom:
>
>[what I am sharing] [who I am sharing it with](options)
>
>If you look at your current set-up, those don't quite seem to match
>up with what I get the impression you'd like NFS to be doing. Your
>who, what, and where might need some sorting out, and you'll want to
>check the /etc/fstab and /etc/exports files on both machines to make
>sure the information matches up nicely.
>
>====================
>
>Here's your ubuntuserv machine's /etc/fstab line:
>
>192.168.119.216:/home/bosse/www/video /mnt/video nfs tcp,noexec,intr
>0 0

No, this is the Ubuntu Mint *client* machine's /etc/fstab line in order to
connect to the ubuntuserv NFS share!

ubuntuserv = IP 192.168.119.216

The Mint *client* machine is named aspomint and uses IP 192.168.117.251

>====================
>
>My reading of your ubuntuserv /etc/fstab line is:
>
>The machine at the 192.168.119.216 IP is sharing
>the /home/bosse/www/video directory with me and I can find it in
>my /mnt/video directory and these are the options that must be used.

Except it is the aspomint fstab file pointing towards the ubuntuserv share

>
>====================
>
>Here are your ubuntuserv machine's /etc/exports lines:
>
>/home/bosse/www/video 192.168.119.0/24(rw,sync,no_subtree_check)
>/home/bosse/www/video 192.168.117.0/24(rw,sync,no_subtree_check)
>
>====================
>
>My reading of your ubuntuserv /etc/exports lines is:
>
>I am sharing my /home/bosse/www/video directory with the machines at
>the 192.168.119.0 through 192.168.119.255 IP addresses and these are
>the options that must be used.
>
>I am sharing my /home/bosse/www/video directory with the machines at
>the 192.168.117.0 through 192.168.117.255 IP addresses and these are
>the options that must be used.
>

This is a mistake that I corrected in a later post:
I thought at first that every export definition for a client to connect to was
on a separate line but in fact the exports file is organized *differently* with
a space separated list of clients in a *single* line for each shared directory:

<path to shared dir> <-default options> <client1 name or IP> <client2> etc

>====================
>
>I get the feeling that's not quite what you want those lines to say.
>
>Your /etc/exports lines look like they do what you're after as long
>as /home/bosse/www/video is on the ubuntuserv machine and as long as
>it wants to share that directory with any machine at any of the
>specified IP addresses.
>
>It's the /etc/fstab line on ubuntuserv that seems to be what's
>messing things up. I get the impression that that line should be in
>the remote machine's /etc/fstab file and not on ubuntuserv and it
>should contain ubuntuserv's IP

This is a misread of my post probably because I included the *comment line*
before the line in the fstab file on the *client* where it describes what it is
connecting to....

So I have showed the fstab file on the *client* side and the exports file on the
*server* side.

And initially I had erroneously added a second line in the exports file to
declare another client to the same share, when correct formatting is to add the
second client to the end of the existing line for the shared directory.

In fact if the two LAN address ranges could be entered in an acceptable way in
one expression there would be no need for a second client entry.

So if 192.168.119.0/24 and 192.168.117.0/24 could be written combined in one
single composite maybe using a wildcard or similar then I need only one client
define.
But I think 192.168.11*.0/24 is not valid....


Please note that before I moved the client device to the remote LAN it was
operating just fine on my home LAN concerning mounting the NFS share to a
192.168.119.xxx client address.

When it moved to the remote LAN it got the address 192.168.117.251 and even
though the LAN-LAN connection works fine for everything else it did not connect
the NFS share, which is of course clear by the exports file on the server
allowing only 192.168.119.xxx addresses.

But after I have now changed the exports file to *include* clients with the
192.168.117.xxx addresses it still does not work....

Maybe I could use this instead in the exports file:

/home/bosse/www/video 192.168.116.0/22(rw,sync,no_subtree_check)

Only using the front 22 bits of the address (using /22) would match all
addresses from 192.168.116.0 to 192.168.119.255, which would bring in two more
8-bit subnets but that is not really a concern here.

But, for some reason this too does not work, same error message!

>>Then I did this:
>>
>>sudo exportfs -a
>>sudo systemctl restart nfs-kernel-server


>Here are the commands I would use after making changes (see man
>exportfs for why the r option might be helpful):
>
># Restart NFS:
>	sudo exportfs -ar
>	sudo systemctl restart nfs-kernel-server

Now I have repeated my commands using the -ar option.
After this I tried to connect from the client but got the exact same response 
(I am now testing on the command line before modifying fstab and doing a mount
-a) :

$ sudo mount 192.168.119.216:/home/bosse/www/video /mnt/video
mount.nfs: access denied by server while mounting
192.168.119.216:/home/bosse/www/video

Is it possible to expand verbosity of the mount command to include the *actual*
reason for the denial?

># Restart the network:
>	sudo systemctl restart systemd-networkd
>

So the difference is that you also restart the complete networking?

But when I also did that I still got the error on the client mount command...

Note too that this client *can* connect to another home LAN NFS server (on my
Synology NAS) without problems, it is just this ubuntu server's NFS share that
is not connectable.

ALMOST GIVING UP....
--------------------
After all this I am considering rebooting the server entirely even though that
should not be needed. It seems like I am missing some vital detail in making the
nfs server read its config in the /etc/exports file...
What could that be?

While I am doing all this the nfs video share is mounted to two other Ubuntu 20
machines on the 119 LAN and these continue to work during these constant
restarts...
Is it really restarting? How can I find out?


-- 
Bo Berglund
Developer in Sweden