A little background info, since there seems some confusion about various concepts.
NFSv3 does not authenticate users, it authenticates machines, based on their IP address. If the client’s IP is allowed access, the client will be able to mount the remote drive to a local folder. You can verify this on the client using the “df” or “mount” commands. (fstab only contains instructions on how to mount something, not whether the mount succeeded or not)
Whether or not a user can write to a mounted NFS share is solely determined by the underlying file system. Linux file systems do not care about user names, however. They rely on the numerical UID of the users and groups trying to perform an action. So if the “pi” account on your NAS has a different UID than the “pi” account on your client, you will not be able to do much.
The UID can be checked with the “id” command and should give you something like:
uid=1023(pi) gid=100(users) groups=100(users),101(media)
So if the UID for the pi user is different on both machines, you will get denied access to the file or directory you are trying to open.
In order to solve this, you could create a user on the NAS with the same UID as the “pi” user on the client and give access to the shared files to that user.
Furthermore, the umask only affects what permissions a newly created file gets, but has no influence on any existing files you are trying to access. Using umask 000 is generally considered a Bad Idea™. It’s the same as giving write access to Everyone on any file you create.
If you want the full background, I suggest reading up on POSIX and ACL-based file permissions. If I remember correctly, Synology’s DSM uses its own style of ACL which is managed by a local database.