Feedback about implementation of NFS

I have a raspberry pi server running: Urbackup, Deluge, Plex and acts as a network server with samba.

Now that I more or less only use linux (still have a windows that I start like once a month), I was thinking of changing the samba share into a share where I have access like it was a hd mounted in Manjaro, so NFS seems to be the solution.

I have another sbc with Armbian as a test server so I set up an NFS server on that.
The tutorials for rpi:s don’t mention the binding and symlinking like mentioned in this root tip so that is my first question.
I see it is also the method on the arch wiki, but I cant really understand why?

The tutorial I followed, got me to do this (I changed to no_root_squash and removed the anonuid and anongid. I figured that out by reading this)
Also: Man page

I set up this on the OrangePi to test:

/etc/exports

/media/share 192.168.1.10(rw,no_root_squash,insecure,async,no_subtree_check)

Then:
sudo exportfs -ra

On debian it seems that the systemd services start after installation, so no need for anything else.

I mounted it on my Manjaro with:
sudo mount -t nfs 192.168.1.30:/media/share /media/share
In the future this will be handled by a systemd.automount

It seems to work as intended, It acts like the share would be an ext4 partition mounted on my computer, I can chown and it denies me access if I don’t sudo a file owned by root (assuming the uid:s and gid:s are the same on Manjaro and the server, witch they are).
But again, is this ok? I will do this directly on the same directory as my samba server is sharing now, without symlinks or anything, what is the downside?

Now I also want to do this the other way around, a server on my Manjaro accessed by 3 smb:s using NFS the same way.
So same question again, do I now HAVE to do the binding and symlinking thing as in the manjaro root tip or can I do the same method but changing /etc/exports to either accept the full network range 192.168.1.0/24 or adding 3 different ip numbers?
Would the crossmnt option come into play?

I tried to explain without too much text covering all I think i necessary.
Thank you in advance.

As I recall my - not very intensive - research on the subject it was created by Sun with the aim of being transparent to the system and accessed in the same manner as local filesystem.

NFS access is a host based access schema - where the user logged on matters less.

On it’s base it is very simple - either you don’t have access and if you have it is either read-only or read-write.

Because of this - being an open source filesystem and native to the *nix world - it is - in my personal opinion - superior to SMB because it is proprietary Microsoft and because it is a lot easier to setup and connect to within a Linux network.

It has the same shortcomings as SMB, that finegrained control requires the user to exist on both server and client - with the same UID - other than that - it just works.

This is not a requirement - but a best practise.

My worklife included being an external sysadmin for SMB - handling their servers and network and user base.

Being sysadmin requires you to think ahead - what will happen in case of breach or malicious activity - thus - using the bind mapping schema is part of it.

dot navigation is made impossible for an attacker which by chance gets physical access through a workstation e.g. cd ../../../usr/bin - a command that will work on the physical structure and is often used by hackers to explore the filesystem - looking for sensitive data worth stealing - but not with the bind mount.

That is so interesting you wrote that because that was the absolute first thing I tried, but could not figure out how, I need to level up my hacking skills. xD

But why is that, what is it actually doing differently? (except for the …/…/… thing?)

Do I understand you correctly if I say that it is basically ok to directly share a subdirectory, it would become a vulnerability if someone gets access to my network with ill intent?
Then I feel pretty safe.

The share is only movies, pictures, documents and such (no sys files) so I opted for the async option, nothing I can’t afford to loose in case of a computer crash (It’s also backed up), would you agree?

I did some further research and it just confuses me even more though.

On the man page for exports under “Subdirectory Exports” it states:

Normally you should only export only the root of a filesystem. The NFS server will also allow you to export a subdirectory of a filesystem, however, this has drawbacks:

First, it may be possible for a malicious user to access files on the filesystem outside of the exported subdirectory, by guessing filehandles for those other files. The only way to prevent this is by using the no_subtree_check option, which can cause other problems.

But earlier under “General Options/no_subtree_checks” they state:

From release 1.1.0 of nfs-utils onwards, the default will be no_subtree_check as subtree_checking tends to cause more problems than it is worth. If you genuinely require subtree checking, you should explicitly put that option in the exports file. If you put neither option, exportfs will warn you that the change is pending.

So they kinda contradict themselves in my eyes.
I also have no_subtree_check selected sooo, I’m still a bit confused.
Or am I missing something here?

While it may seem contradicting - the following sentence explains why

I usually provided data from a subfolder - which is also why I use bind mount - because the bind mount removes access to the folders above the shared data.

Not really, since if subtree_check is disabled (like it also is by default) the whole part about it being insecure: “The only way to prevent this is by using the no_subtree_check option, which can cause other problems”, is contradictive, because they state that NOT using “no_subtree_check” causes MORE problems…?

Again:

From release 1.1.0 of nfs-utils onwards, the default will be no_subtree_check as subtree_checking tends to cause more problems than it is worth.

Edit
I don’t want you to defend anything, I just want to confirm I am not crazy here…