Is idmapd supposed to work where users have different uid numbers on the nfsv4 server and client? It seems to show the right names for ownership on the client side, but if I automount a home directory, that user doesn't have permission to enter it, and if I change permission to allow access and create a new file, it shows on the server as owned by the uid number for the user on the client (and wrong on the server).
Everything works like it would on nfs v3 where the uid numbers are the same on the client and server, but what's the point of the rpcidmapd daemon if it doesn't actually map the ids?
On 8/27/13 12:01 AM, Les Mikesell wrote:
Is idmapd supposed to work where users have different uid numbers on the nfsv4 server and client? It seems to show the right names for ownership on the client side, but if I automount a home directory, that user doesn't have permission to enter it, and if I change permission to allow access and create a new file, it shows on the server as owned by the uid number for the user on the client (and wrong on the server).
Everything works like it would on nfs v3 where the uid numbers are the same on the client and server, but what's the point of the rpcidmapd daemon if it doesn't actually map the ids?
As far as I know, nfs4 doesn't care about UID/GID, but checks names, so it should work, no matter that you have different UIDs on server and client for same users.
Cheers, Barbara
On 8/28/13 9:37 AM, Barbara Krasovec wrote:
On 8/27/13 12:01 AM, Les Mikesell wrote:
Is idmapd supposed to work where users have different uid numbers on the nfsv4 server and client? It seems to show the right names for ownership on the client side, but if I automount a home directory, that user doesn't have permission to enter it, and if I change permission to allow access and create a new file, it shows on the server as owned by the uid number for the user on the client (and wrong on the server).
Everything works like it would on nfs v3 where the uid numbers are the same on the client and server, but what's the point of the rpcidmapd daemon if it doesn't actually map the ids?
As far as I know, nfs4 doesn't care about UID/GID, but checks names, so it should work, no matter that you have different UIDs on server and client for same users.
Cheers, Barbara _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sorry, if you use nfs4 and idmapd uid/gid has to be the same on server and client. I have tested and it does not work when UID differs on server/client.
Cheers, Barbara
On Wed, 28 Aug 2013 10:27:18 +0200 Barbara Krasovec barbarak@arnes.si wrote:
On 8/28/13 9:37 AM, Barbara Krasovec wrote:
On 8/27/13 12:01 AM, Les Mikesell wrote:
Is idmapd supposed to work where users have different uid numbers on the nfsv4 server and client? It seems to show the right names for ownership on the client side, but if I automount a home directory, that user doesn't have permission to enter it, and if I change permission to allow access and create a new file, it shows on the server as owned by the uid number for the user on the client (and wrong on the server).
Everything works like it would on nfs v3 where the uid numbers are the same on the client and server, but what's the point of the rpcidmapd daemon if it doesn't actually map the ids?
As far as I know, nfs4 doesn't care about UID/GID, but checks names, so it should work, no matter that you have different UIDs on server and client for same users.
Cheers, Barbara _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Sorry, if you use nfs4 and idmapd uid/gid has to be the same on server and client. I have tested and it does not work when UID differs on server/client.
Cheers, Barbara
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
http://dfusion.com.au/wiki/tiki-index.php?page=Why+NFSv4+UID+mapping+breaks+... BR, Bob
On 08/27/2013 12:01 AM, Les Mikesell wrote:
Is idmapd supposed to work where users have different uid numbers on the nfsv4 server and client? It seems to show the right names for ownership on the client side, but if I automount a home directory, that user doesn't have permission to enter it, and if I change permission to allow access and create a new file, it shows on the server as owned by the uid number for the user on the client (and wrong on the server).
Everything works like it would on nfs v3 where the uid numbers are the same on the client and server, but what's the point of the rpcidmapd daemon if it doesn't actually map the ids?
for nfsv4 it is my understanding you need a central user store like ldap or nis (but don't use nis) or synchronize your password file to eternity. I do not have a centos nfs server (or a linux one, for that matter, what I want from nfsv4 are mainly the extended acls and those are not there until somebody wakes up and merges the richacl patch into the mainstream kernel), only clients, but they work fine using nfsv4 to both netapp as zfs (omnios) filers.
Both the clients as the filers are configured to lookup up users in ldap (ipa in our case).
I have no experience with idmapd in linux, but in solaris and netapp it gets ugly quite easily :-)
On 8/28/13 11:29 AM, natxo asenjo wrote:
On 08/27/2013 12:01 AM, Les Mikesell wrote:
Is idmapd supposed to work where users have different uid numbers on the nfsv4 server and client? It seems to show the right names for ownership on the client side, but if I automount a home directory, that user doesn't have permission to enter it, and if I change permission to allow access and create a new file, it shows on the server as owned by the uid number for the user on the client (and wrong on the server).
Everything works like it would on nfs v3 where the uid numbers are the same on the client and server, but what's the point of the rpcidmapd daemon if it doesn't actually map the ids?
for nfsv4 it is my understanding you need a central user store like ldap or nis (but don't use nis) or synchronize your password file to eternity. I do not have a centos nfs server (or a linux one, for that matter, what I want from nfsv4 are mainly the extended acls and those are not there until somebody wakes up and merges the richacl patch into the mainstream kernel), only clients, but they work fine using nfsv4 to both netapp as zfs (omnios) filers.
Both the clients as the filers are configured to lookup up users in ldap (ipa in our case).
I have no experience with idmapd in linux, but in solaris and netapp it gets ugly quite easily :-)
It also works with same UID-s on server/client, just setting the domainname in idmapd.conf. Ldap is not obligatory. Cheers, Barbara
On Wed, Aug 28, 2013 at 11:04 AM, Barbara Krasovec barbarak@arnes.si wrote:
I have no experience with idmapd in linux, but in solaris and netapp it gets ugly quite easily :-)
It also works with same UID-s on server/client, just setting the domainname in idmapd.conf. Ldap is not obligatory.
This is a small lab-type setting but I'm trying to merge two sets of machines set up by different groups to have a common home directory server that all the others automount. The number of users is small enough that I'll just 'usermod' them into the same uid numbers, but I don't see why it is worth running the idmapd daemon at all, when all it does is map everyone to nobody if you forget to set the domains identically. And after fixing the uids to match, is there any advantage to nfsv4 at all?
----- Original Message ----- | On Wed, Aug 28, 2013 at 11:04 AM, Barbara Krasovec | barbarak@arnes.si wrote: | > >> | >> I have no experience with idmapd in linux, but in solaris and | >> netapp it | >> gets ugly quite easily :-) | >> | > It also works with same UID-s on server/client, just setting the | > domainname in idmapd.conf. Ldap is not obligatory. | | This is a small lab-type setting but I'm trying to merge two sets of | machines set up by different groups to have a common home directory | server that all the others automount. The number of users is small | enough that I'll just 'usermod' them into the same uid numbers, but I | don't see why it is worth running the idmapd daemon at all, when all | it does is map everyone to nobody if you forget to set the domains | identically. And after fixing the uids to match, is there any | advantage to nfsv4 at all?
Over NFSv3? Yes, single port for traffic and extended ACLs. Throw in Kerberos and you have authenticated access to resources.
On Wed, Aug 28, 2013 at 11:29 AM, Les Mikesell lesmikesell@gmail.com wrote:
This is a small lab-type setting but I'm trying to merge two sets of machines set up by different groups to have a common home directory server that all the others automount. The number of users is small enough that I'll just 'usermod' them into the same uid numbers, but I don't see why it is worth running the idmapd daemon at all, when all it does is map everyone to nobody if you forget to set the domains identically. And after fixing the uids to match, is there any advantage to nfsv4 at all?
Reviving an old thread... I had this all working with an initial set of users across several machines where all users had the same user id and idmapd.conf had the same Domain set. /home is exported from one machine, and everything showed the right ownership. However, when I add new users, again keeping the same uid numbers across all hosts, the mounted instances show as 'nobody' for the new users. Is there some magic short of a reboot to make it recognize the new user ids? A reboot does fix it, 'service rpcidmapd restart or force-reload' does not, unmounting /home and remounting also does not.
On 08/28/2013 06:04 PM, Barbara Krasovec wrote:
On 8/28/13 11:29 AM, natxo asenjo wrote:
for nfsv4 it is my understanding you need a central user store like ldap or nis (but don't use nis) or synchronize your password file to eternity. I do not have a centos nfs server (or a linux one, for that matter, what I want from nfsv4 are mainly the extended acls and those are not there until somebody wakes up and merges the richacl patch into the mainstream kernel), only clients, but they work fine using nfsv4 to both netapp as zfs (omnios) filers.
Both the clients as the filers are configured to lookup up users in ldap (ipa in our case).
I have no experience with idmapd in linux, but in solaris and netapp it gets ugly quite easily :-)
It also works with same UID-s on server/client, just setting the domainname in idmapd.conf. Ldap is not obligatory.
that's why I wrote 'synchronize your password file to eternity' ;-)
But really, don't do that, use a central store. Much easier unless you have a very very tiny network (but those tend to grow unexpectedly).
On Wed, Aug 28, 2013 at 1:10 PM, natxo asenjo natxo.asenjo@gmail.com wrote:
I have no experience with idmapd in linux, but in solaris and netapp it gets ugly quite easily :-)
It also works with same UID-s on server/client, just setting the domainname in idmapd.conf. Ldap is not obligatory.
that's why I wrote 'synchronize your password file to eternity' ;-)
But really, don't do that, use a central store. Much easier unless you have a very very tiny network (but those tend to grow unexpectedly).
This is a very tiny subset (mostly) of a corporate network where the larger things are handled by active directory. But, for various non-technical reasons I don't want these machines to have to 'join' AD. Kerberos will sort-of work without joining, but doesn't seem usable for exporting samba shares - and then anyone added locally wouldn't work without the uid matching anyway. Is there a way to set up an LDAP server with a few local users but that mostly does a proxy to AD? And if I did, would users be able to map their home directories as samba shares with the authentication it provides without joining AD?
On 08/28/2013 08:24 PM, Les Mikesell wrote:
This is a very tiny subset (mostly) of a corporate network where the larger things are handled by active directory. But, for various non-technical reasons I don't want these machines to have to 'join' AD. Kerberos will sort-of work without joining, but doesn't seem usable for exporting samba shares - and then anyone added locally wouldn't work without the uid matching anyway. Is there a way to set up an LDAP server with a few local users but that mostly does a proxy to AD? And if I did, would users be able to map their home directories as samba shares with the authentication it provides without joining AD?
you could install the IdM solution and create a cross realm trust between both domains. Not trivial, but would do what you want to accomplish.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
You would need cooperation from your AD admins though. That might be a problem in some environments.
It is quite a big project, though.
On Wed, Aug 28, 2013 at 1:39 PM, natxo asenjo natxo.asenjo@gmail.com wrote:
This is a very tiny subset (mostly) of a corporate network where the larger things are handled by active directory. But, for various non-technical reasons I don't want these machines to have to 'join' AD. Kerberos will sort-of work without joining, but doesn't seem usable for exporting samba shares - and then anyone added locally wouldn't work without the uid matching anyway. Is there a way to set up an LDAP server with a few local users but that mostly does a proxy to AD? And if I did, would users be able to map their home directories as samba shares with the authentication it provides without joining AD?
you could install the IdM solution and create a cross realm trust between both domains. Not trivial, but would do what you want to accomplish.
https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/...
You would need cooperation from your AD admins though. That might be a problem in some environments.
It is quite a big project, though.
The AD admins are in a different group in a different location and involving them adds a lot of complexity. A short script to 'usermod -u nnn' everyone into the same uids across hosts sounds better all the time. However, it would be nicer if there were some way to avoid having to manage yet another password for each user for samba, although with central home directories that would only need to be on one of the systems.
-
Barbara Krasovec -
Bob Marcan -
James A. Peltier -
Les Mikesell -
natxo asenjo