Linux NFS – set default user for new files on nfs share

It's confusing to try to understand what your problem is, you don't make it clear if you're checking a file on web1 on web1, or db1 on web1, or whatever. Please give a good description of what's you're actually seeing, without confusing the issue with copying and chmoding. Something simple like I create a file on db1, with permissions x:y and on web1 I see permissions a:b and on web2 I see permissions c:d.

First thing, using NFS, any file which is owned by root will usually be shared so that it's owned by nobody. This means that if you have root on the client machine, you effectively don't have root on the server. I think that explains some of what you're seeing.

Secondly, if you are running NFS, it's vital that the userid->username mappings are identical on all the servers. Unix filesystems only store a numeric id for userid & groupid, which are then mapped to usernames by programs like ls. Are you sure that they are all in sync? It could be that you've got a mismatch.

Finally, tar p is an option for extracting, not creating tars. It's ignored when creating tars, and even when it's used, it's not going to set the ownership to what they originally were. -p basically means, ignore the umask. Tar will create files owned by you only, unless you're root.

So you did

setfacl -m d:u:root:rwx,d:g:"sharegroup":rwx,d:other:--- share

Anything you do with setfacl d: (known as "default ACL") does not impact ownership, only the accessibility. So you can decide "who can access", but not "who owns". You've just caused the test files to have rwx access for the owning user and for root; and rwx access for the owning group and for the "sharegroup". But the owning user and owning group were determined exactly the same way as without setfacl.

The permissions of files are unexpected, because with setfacl'd file, the umask is no longer taken into account. Each file has its "own umask", known simply as mask (see getfacl).

And you did

chmod 2770 share

Wrong again. 2770 is not sticky, this is setgid bit. Sticky would have been 1770. The setgid changed the owning group for the new files, and did not impact their permissions at all. The permissions, as usual, take into account umask (see umask) and mode suggested by application creating the file.

I'm not aware how can the thing you require be properly implemented with the tools you have. There is no "setuid for directories" implemented in Linux.