NFSv4 does user@DOMAIN lookups (not simple UID/GID enforcement like NFSv3) so you need to have the same authentication database (files, LDAP, whatever) on both systems. With v3 all you need is to have the same UID/GID as the file...not necessarily the same username. If you don't need any of the features of v4, I'd recommend going with v3 on Linux. Historically, Linux has had a pretty flaky v4 implementation.
Yes, adding a new non-root user, then sudoing from it is the "best-practice". If you have a lot of commands to run at once many people say to run sudo su -. However, sudo has a -i option that is used to give you a root shell.
Also, if you want to disable interactive logins for root, you can change the password in /etc/shadow to '!'.
To have two users access the same files, you would create a new group (lets call it 'shared'):
$ sudo groupadd shared
Then you would add your users to it:
$ sudo usermod -a -G shared meder
$ sudo usermod -a -G shared www-data
Then on any file or directory you want both to access, you would change the group ownership of the file/directory:
$ sudo chgrp share [path-to-file]
If you want user's in the group to have full permissions to the files you may have to change the file permissions as well:
$ sudo chmod g+w [path-to-file]
or
$ sudo chmod 775 [path-to-dir]
Read man chmod for a description of the various permission syntaxes.
Finally, you will often want to set the group bit so that new files created are created with the group owning the directory instead of your default group. For example, when you create the user 'meder' useradd will create a "user private group" that will be called 'meder' and user 'meder' will be the only member. This means when you create new files they will be owned by meder:meder (user meder and group meder). If you want them to be owned by the group shared, you must set the group id bit on the directory. To do that, you need:
$ sudo chown g+s [path-to-dir]
A full example would be:
$ sudo -i
# mkdir /opt/shared
# groupadd shared
# usermod -a -G shared meder
# usermod -a -G shared www-data
# chgrp shared /opt/shared
# chmod 775 /opt/shared
# chmod g+s /opt/shared
# exit
The only issue I've come across with this is that most files are created with 755 or 644 permissions, which means you always have to manually add group write permissions to files in the shared folder. There's probably a way around this, I just don't know it.
Lastly, you don't have to create the shared group. You could just add 'meder' to the www-data group and do the rest with that group.
Best Answer
I don't know much about Debian and neither about NFSv4.
But if the mount options are still the same as with NFSv3 my favorites (for any nfs-client-mount an any os) are:
rsize and wsize are tuned up to reasonable sizes per default nowadays - look at your lokcal man-page.
I used to use "wsize=32768,rsize=32768" to get better tranfer rates before that.
You also have to take care on the nfs-server-side (if NFSv4 is still the same here as NFSv3):
Else the client will try to reconnect against an empty "nfs-service" and will fail instead of retry.
BTW - what has SAN to do (in this case) with Sun Unified Storage? What happened when you "lost" your SAN? Why did the rebuild process break things? Was the storage not redundant?