Hello,
even If I have specified the export option (rw) in /etc/exports I still can't do any write operation into the shared file system unless I also put no_root_squash in there. Why the hell rw exists then? Thank you.

Works here. Probably your user UID does not match.

The directory must be owned|writable by the anonymous NFS user (UID 65534 on most distros).

Must? Certainly not.

Are you root? The way NFS works here (from web-search of no_root_squash) is:
"root over NFS *becomes=IS* '...nobody'!" (my 1990 800-USA-4SUN answer!)
(unless you force: doNOt do dangerous_ROOT_ SQUASH=smashing2nobody)
If you have the Vugt book you discussed in your prior thread,
this is discussed at the bottom of p.787, the 2nd page on NFS.

So, are you *using root* in your trying to 'rw' over NFS?
(typically, root won't write over nfs, unless no_root_squash)
Do non-root [regular] users work ok over your NFS?
Try exporting a perm-mode 777 /test dir and client# touch file;
is the new file owned by nfsnobody (instead of root as expected)?

Don't feel bad: this is a easily-overlooked feature/trick.
And, YES, *without* the server /etc/exports no_root_squash option, it
"must be writable by the anonymous NFS user [nfsnobody] (UID 65534 on most distros)"
for client rw *as root* to work. Tricky! Got-ya? (my 1990 800-USA-4SUN answer!)

Emerson: On the NFS server, I tried to change the users's UID to match the one on the client - now both usernames and UIDs match each other. But I'm not sure if that's what you mean. Anyway it didn't help.

Jjanel:
I tried both to edit an existing file and create a new one on the NFS share with both the root and a regular user with no avail. That is when no_root_squash is NOT set but rw is.
I'm not sure I understand your instruction but if you wanted to say to change the persmissions on the NFS share on the NFS server to 777 and then to create a file there as the client - it's successful. A file created by the root is owned by nfsnobody:nfsnobody and a file created by a regular user (david) is owned by david:nobody. This was done when the no_root_squash was NOT set.
Excuse my nescience but what does it mean?

MadeInGermany & Jjanel:
Well, I guess the filesystem write permissions/ownership for nfsnobody as you both pointed out are the key factors here.

Thank you all for the help.

As long as you are *not* uid root on client, (if uid david in your example)
all works as expected (whether or not no_root_squash is used in server exports).

The security issue is: allowing root on clients to have
the same root access on the server, without any authentication.
On a home network, if you are root on a client,
you probably want the same root access on the server
(since all the systems are yours).
In a larger company, you don't want every client (that some untrusted person setup!)
to have full&unrestricted file access to the [nfs] server, as root! (as basic default)
You want root on a [possibly 'rogue'] client to be limited ['squashed'/remapped]
to something like an untrusted [nfs]nobody on the server. (as basic default)
This is the idea behind NFS squash=change=switch=translate=remap=...[loose synonyms]
root on a client, into '...nobody' on the server [instead of leaving id root].
(as default; there's other options on exporting to certain trusted clients explicitly)
no_root_squash is often used with "ro", to allow/trust just reading (by any/all clients)

So, NFS was designed with the logic:
[client] *"root becomes=IS nobody"* [on the NFSserver]
unless you explicitly specify that root on the client should be root on the server, via
no_root_squash [no root remap-to-nfsnobody]. For clarity, you can simulate the absence of no_root_squash by:
client # su nfsnobody
client $ ...operate on files on the nfs-server... (thus as user-id nfsnobody)

A web-search of just no_root_squash returns a lot on this ['tricky'] feature.

(excuse my joking about when I used to answer this 'faq' in 1990, when I worked at 1-800-usa-4SunMicrosystems, way back in 1990!)

This should do the trick for access by that user, in directories created by that user (after the UIDs match). It will do nothing to help root access (nor should it-it's not supposed to).

I think that maybe you have gotten tripped up by the ownership/permissions on the parent directory of the files/directories you are testing with.

On my own systems, the UIDs and GIDs for the users match, and I have no problems with access on nfs shares that don't have "no_root_squash" set. For all practical purposes, root has no access to any of those shares, but that's okay by me. I understand why this is the default way nfs works. I also have some nfs shares with "no_root_squash" because it is necessary (like for diskless nfs root).

I have not messed around with customizing access for "nobody". I am okay with the default, which is that "nobody" has practically no access.
If no_root_squash is not set, then root should not have been able to edit either an existing file or create a new one; this is by design.

Assuming the UIDs match on the regular user, then editing an existing file (created by that user since matching the UIDs) should have worked. Trying to create a new file would depend upon the ownership/permissions on the parent directory.
This indicates that even though the UIDs match, the GIDs (group ID) do not match. I'm honestly not sure exactly what effect this has on things. It's probably not ideal, but I think it's not a show stopper.