After wasting a lot of time trying to remap UIDs for an NFS mount using idmapd, I came across this article.

In summary:

“The problems start when we want to access the file contents or modify a file/directory and suddenly we get ‘permission denied’ type messages. Now NFS itself doesn’t do the security authentication but delegates it down to the underlying RPC mechanism.

Ok so we move down a level and look at RPC’s security. Well AUTH_SYS on RPC is just as it has been for the last umpteen years – based on uid/gid. The problem is these uids/gids are sent over the wire (just as they always have been).
“But”, says you, “Isn’t this what the whole NFSv4 id mapping feature was meant to fix!”
Ahh – there’s the rub.
RPC hasn’t been augmented to support such mapping.
Since RPC still send’s uid/gid over the wire the whole uid<->username mapping seems pretty useless in practice for the above common scenario (if you control the entire network then uids and gids are typically the same and there is no matching problem in the first place).”

You can’t modify files if you’re using AUTH_SYS (check this with an exportfs -v, if you see sec=sys in the export options, you are) with idmapd unless you make them world writeable. You can’t enter directories unless they’re world-executable.