How to make nfs share accessible across subnets?

[Little Girl]

Hey there,

Bo Berglund wrote:
>Little Girl wrote:

>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!

If it's any consolation, I feel your pain. We've often had to wrestle
with NFS.

>>>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*.

Okay, that's no problem. I've never done that, but I see an example
of it in the default text inside the /etc/exports file.

>>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!

Okay, that makes more sense. Now for some questions:
* Is 192.168.119.216 the IP of ubuntuserv?
* Is /home/bosse/www/video a directory on the ubuntuserv machine?
* Is /home/bosse/www/video the directory that the ubuntuserv machine
  wants to share?
* Is /mnt/video a directory on aspomint?

Note that I've seen you use upper-case letters for VIDEO in some of
your examples and case matters, so if it should be upper-case, that
might take care of it right there.

>ubuntuserv = IP 192.168.119.216

Okay, that answers the first of the four questions above.

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

Okay.

>>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....

No problem.

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

That's nice and clear.

>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.

What does your /etc/exports line look like now?

>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....

No idea. You're out of my league with that one.

>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.

Has anything else changed besides the change in IP, like perhaps a
new firewall on one or both machines? Also, have you tried this with
static IPs?

>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....

This is definitely the odd part.

>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!

This is another one that's out of my league.

>># 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) :

Okay.

>$ 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 all of 192.168.119.216:/home/bosse/www/video valid for ubuntuserv
including the case of the directory?

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

The mount command accepts the -v option that's worth a try.

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

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

Yep.

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

That's a shame, but it was worth a try.

>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.

I've got one other possibility. Have you tried adding the users
option to the /etc/fstab line?

>ALMOST GIVING UP....
>--------------------
>After all this I am considering rebooting the server entirely even
>though that should not be needed.

I doubt that would make a difference, but it's worth a try.

>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?

I'm hoping it's the case of the directory name.

One other thought is that your other files related to NFS may need to
be updated after the network change. Did you update the hosts.allow
file after the network change?

>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?

It should show up in the /var/log/auth.log file. It does on my system.

You might also want to check out man showmount to see if the
showmount command would be useful. You can do showmount -e to check
the exports on the current machine or you can do showmount -e
hostname to check the exports on a different machine.

Last, but not least, when something like this happens to me and I
just simply can't figure out what I'm missing, my strategy is to wipe
out what I've currently got (remove all traces of NFS from the
offending machines) and start over. You had it working once before,
which means you know what you're doing. Perhaps if you go through all
of the steps again from the ground up, it will sort itself out.

-- 
Little Girl

There is no spoon.