here we have the problem with understanding how the NFS works.
The situation:
we have two servers - SLES 10 and SLES 11 with NFS enabled. For users
we use local password file method.
with SLES you have two options - you can use default NFS settings (v.3
I guess) and you can use v.4 NFS options that includes user mapping
daemon.
And the v.4 option is supported only in SLES 11 client (I can’t find
any remarks about it in SLES 10 NFS client).
Then we have two identical users on both computers with some rights to
files and folders (complex enough, actually they are Oracle accounts).
And we need to give access for the user from one server to another via
NFS with user mapping.
So we have the following results:
If the user ID on both servers are identical (104 for example) - there
are no problem even if we use default NFS settings.
But if the user ID differs (104 on one server and 105 on other) - there
is no option to map one ID to other even if we use “true” v.4 NFS
settings (with editing idmap.conf).
I read RTFM and found very poor information about v.4 NFS configuring,
so now I can’t understand the basic function:
if NFS v.4 can only map user with identical ID from one server to
other, then I have no chances with mapping users with identical IDs
if there is somwhere more sophisticated configuring for NFS v.4,
where this option is available (may be NFS upgrade needed), please point
me there
I don’t have a full explanation of how idmapd works and what various
configurations will or won’t work in specific environments, but here’s a
couple points I can offer:
SLES 10 supports nfsv4 (both as client and server) also, it doesn’t
have to be SLES 11.
To my understanding idmapd is supposed to automatically map between
users of the same name, even if they do not have the same UID. Many
people find that is not working by default on their systems, and they
benefit from TID 7005060.
Thank you for reply…
I’ve read this TID but found it useless - there is no explanation of
Mapping section of the idmapd.conf file, only default entries.
I’ve done plenty of experiments and noticed the following:
I can change ID interpretation with defaults in idmapd.conf only on
client side.
If I use nfs option with mount, it maps IDs from remote server to
user names from local password file.
If I use nfs4 option with mount, it shows true (remote) user names.
This is mapping ID in work.
BUT the server itself ALWAYS map client ID to local name. So if on the
client side user have ID 105, I found no way to map it to the username
with ID 104 on server.
The final task is to grant local rights to files to remote user.
I think Mapping section CAN do it, but I failed to google some examples
or explanations.
I’m sorry, I guess I’m not very useful for idmapd. I can offer slightly
more info than I did before (plus considerable empathy) but I don’t
really have the answers you seek.
You wrote:[color=blue]
there is no explanation of Mapping section of the idmapd.conf file,[/color]
only default entries.
As far as I can tell, it is a misconception to think that you get to
define user mappings manually by using the [Mapping] section, or that
there can be entries other than the ‘defaults’. I’m only going by the
man page for idmapd.conf, which says that the variables allowed in the
Mapping section are Nobody-User and Nobody-Group. That seems to imply
that no other variables would be valid for that section. So, as far as
I can tell, individual user mappings would rely on correctly setting up
your domain so that idmap can figure that stuff out. But I’m not
entirely sure what “correctly setting up your domain” would look like.
I did some testing in a manner that seems similar to what you
described… and I was having problems like yours. So I began to
re-examine my lack-of-understanding of idmapd.
Previously, I was under the impression that idmapd would allow you to
have a server and a client with different UIDs/GIDs for the same
usernames, and it would automatically figure out how to map those for
you by passing names over the wire instead of UIDs. But according to
what I’m starting to find in different places online (which I’m not
fully understanding yet) some people appear to be saying that with
idmapd, within any domain, you have to have a common authentication
mechanism so that all names / uids / gids are in agreement. My reaction
is, “Okay, but then… if you have that… why would you need idmapd?”
It may be that instead of idmapd being intended to map joe on host1 to
joe on host2 (all within one domain), that it is instead supposed to
help map between joe@domain1 to joe@domain2 (but all occurrances of
joe@domain1 have to be in agreement already, as do all occurances of
joe@domain2). I started trying to test that distinction by setting up
another domain, but I had no more success or clues or clarity come
about.
Obviously idmapd uses some paradigm more complicated than I have
grasped yet. Sounds like we’re both in the same boat. Anyway, for the
moment all I can say is that if you get your various systems resolving
names/IDs against a common database, then you should avoid problems.
But it you specifically were hoping for something that could map users
for you and allow you to avoid using a common database, you might be out
of luck. Not sure.