ok... seem to have resolved this..
centos 6.8 running test master/client nfs on the masterside: change the /etc/idmapd.conf # The following should be set to the local NFSv4 domain name # The default is the host's DNS domain name. Domain = localdomain <<<<<< # The following is a comma-separated list of Kerberos realm # names that should be considered to be equivalent to the # local realm, such that <user>@REALM.A can be assumed to # be the same user as <user>@REALM.B # If not specified, the default local realm is the domain name, # which defaults to the host's DNS domain name, # translated to upper-case. # Note that if this value is specified, the local realm name # must be included in the list! #Local-Realms = [Mapping] Nobody-User = crawl_user <<<<<<< Nobody-Group = crawl_user <<<<<<< . . . ===================================== changed the user to the user i want on both the master/client... i set the user/group to the same id on both usermod -u 600 user1 groupmod -g 600 user1 i then made sure the given dir on the master/client was "set" client chown crawl_user:crawl_user /dir1 master chown crawl_user:crawl_user /dir1 on the master side... made sure the nfs was reset.. service nfs restart on the client... umount /dir1 mount a ---- for the fstab on the masterside,, update the /etc/exports as required on the client update the /etc/fstab as required.. now.. . on both the master/client for the nfs.. it appears that i have the file owner/perms.. On Fri, Jul 8, 2016 at 4:10 PM, bruce <badoug...@gmail.com> wrote: > arrrgghh.. > > as a drop/kick.. > > I went into the test master/client > -changed the uid/gid for the test user user1 to be 600 > usermod > groupmod > > i didn't reboot > > i shut down the nfs on the master > i did an unmount umount on the client, followed by a mount -a to reinvoke > the fstab > > in the client fstab i have > #test to set the client nfs/mount > 192.168.1.45:/cloud_crawl /cloud_crawl nfs defaults 0 0 -o uid=600 -o > gid=600 > > on remounting the nfs share... > > i still have a different user.. the initial user.. > > thoughts??!! > > > > On Fri, Jul 8, 2016 at 3:32 PM, bruce <badoug...@gmail.com> wrote: > >> Hey.. >> >> Yeah, I had seen a few articles that pointed to the idmapd as being a >> possible issue.. >> >> This is for a test internal -- 192.168.1.* group of 3-4 systems. So, >> there's no real domain, but .... >> >> >> >> On Fri, Jul 8, 2016 at 2:20 PM, Tom Horsley <horsley1...@gmail.com> >> wrote: >> >>> On Fri, 8 Jul 2016 13:57:24 -0400 >>> bruce wrote: >>> >>> > I know, I could just chown, etc.. after the fact.. but I'd like to >>> figure >>> > out how it should be done!! >>> >>> I only know it is the most confusing NFS topic :-). It seems to work >>> OK if all the machines are getting their users from the same >>> source (NIS, LDAP, SSSD, something like that). There is some idmapd >>> thing that turns my brain to cheese when I try to read about it. >>> >>> I have done desperate things like edit the /etc/idmapd.conf and >>> set Nobody-User and Nobody-Group to the user I happened to know >>> I wanted to own files because I could never get any other aspect >>> of idmapd to work :-(. >>> -- >>> users mailing list >>> users@lists.fedoraproject.org >>> To unsubscribe or change subscription options: >>> https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org >>> Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct >>> Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines >>> Have a question? Ask away: http://ask.fedoraproject.org >>> >> >> >
-- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://lists.fedoraproject.org/admin/lists/users@lists.fedoraproject.org Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
