nfs client ownership

[bruce]

Hey.

Simple question, but can't seem to solve it.

Test nfs server works

Copy file to the test dir..

On the master, the test file cat.txt is owned by 'user1'

I have a user1 on the client box, and I'd like any files copied to the nfs
to be shown as owned by the 'user1' on the client nfs box..

I've looked into the mount command, as well as diff articles on the
fstab/mount process, but can't seem to resolve this.

Any pointers??

Thanks

I know, I could just chown, etc.. after the fact.. but I'd like to figure
out how it should be done!!

[Tom Horsley]

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 :-(.

[bruce]

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  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
> [e-mail]
> To unsubscribe or change subscription options:
> https://lists.fedoraproject.org/admin/lists/[e-mail]
> 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

[bruce]

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  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  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
> > [e-mail]
> > To unsubscribe or change subscription options:
> > https://lists.fedoraproject.org/admin/lists/[e-mail]
> > 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

[bruce]

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  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  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 
> > 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
> > > [e-mail]
> > > To unsubscribe or change subscription options:
> > > https://lists.fedoraproject.org/admin/lists/[e-mail]
> > > 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

[Boris Epstein]

Does user1 (and other users) have the same UID on all the systems involved?
I think this is the key moment here.

Cheers,

Boris.

On Fri, Jul 8, 2016 at 7:13 PM, bruce  wrote:
> 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  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  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 
> > > 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
> > > > [e-mail]
> > > > To unsubscribe or change subscription options:
> > > >
> > > > https://lists.fedoraproject.org/admin/lists/[e-mail]
> > > > 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
> [e-mail]
> To unsubscribe or change subscription options:
> https://lists.fedoraproject.org/admin/lists/[e-mail]
> 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

[bruce]

the test users have the same gui/uid on both the nfs server as well as the
client...

I tested this, prior to setting the idmap process

On Sat, Jul 9, 2016 at 9:33 AM, Boris Epstein  wrote:
> Does user1 (and other users) have the same UID on all the systems
> involved? I think this is the key moment here.
>
> Cheers,
>
> Boris.
>
> On Fri, Jul 8, 2016 at 7:13 PM, bruce  wrote:
> > 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  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  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 
> > > > 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
> > > > > [e-mail]
> > > > > To unsubscribe or change subscription options:
> > > > >
> > > > > https://lists.fedoraproject.org/admin/lists/[e-mail]
> > > > > 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
> > [e-mail]
> > To unsubscribe or change subscription options:
> > https://lists.fedoraproject.org/admin/lists/[e-mail]
> > 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
> [e-mail]
> To unsubscribe or change subscription options:
> https://lists.fedoraproject.org/admin/lists/[e-mail]
> 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

[Tim]

On Sat, 2016-07-09 at 12:48 -0400, bruce wrote:
> the test users have the same gui/uid on both the nfs server as well as
> the client...
>
> I tested this, prior to setting the idmap process

I think you need to give some more info.  Your initial message seemed to
indicate that files were arriving as owned by user1 (as you wanted).
And I think you wanted files created by any other users to that space to
be virtually chowned to user1 as they transferred.  Did I get that
right?

What I'm not sure about is where the files get owned by user1.  On the
server, on their own machine, or in multiple places?

And with another message, you mentioned some mounting parameters:
> > 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

Firstly, I *think* you may be doing that backwards (I suppose it depends
which way the files are going).

If you're trying to change ownership on files going onto the server,
then on the NFS *server* try to squash ownership down to your desired
ID, with the NFS exports configuration (see the man page about
all_squash, anonuid and anongid), rather than mount options (of which
some of the options can only be applied to certain filesystems).

Secondly, check that "defaults" does what you want (that the defaults
are the defaults you think they are).

[Tim]

On Fri, 2016-07-08 at 13:57 -0400, bruce wrote:
> Simple question, but can't seem to solve it.
>
> Test nfs server works
>
> Copy file to the test dir..
>
> On the master, the test file cat.txt is owned by 'user1'
>
> I have a user1 on the client box, and I'd like any files copied to the nfs
> to be shown as owned by the 'user1' on the client nfs box..
>
> I've looked into the mount command, as well as diff articles on the
> fstab/mount process, but can't seem to resolve this.

The supposedly simple solution is to make sure that all users have the
same user and group identification numbers (UID & GID) on both sides of
the connection.  You can, either, ensure that users are created with the
same ID numbers, in the first place, or you can change them after the
fact.

Logout as that user, if you are them.  The rest will need to be done as
root, and could cause odd behaviour if you change the details of a user
that is logged in.

You can do a "ls -n /home" to get a quick look at who has what numbers.

Edit the /etc/passwd and /etc/group files, so that user and group
numbers are the same for the same username and groupname, on one or both
sides of the connection.

Then "chown -r <username>:<groupname> /home/<username>" (substituting
the <variables> for actual names), so that the user continues to own
their files (remember, the name is only what you log-on with, ownership
is actually done by the numbers).

Now, when the user works with files, either side of the NFS connection,
they own them.  Likewise for any other user.  While it may be tempting
to squash all users to the same NFS user, and have everything owned
anonymously, that will cause problems when a file does need to be owned
by the particular user.

The alternatives are to learn how user ID mapping works (and that
feature wasn't available when I first had to deal with this problem, so
I've never gone down that route), or to use another file transfer
protocol (than NFS) that makes use of usernames rather than numerical
IDs.

Having said that, I did try Samba in the dim and distant past, and
(apart from being miles slower to send files in one direction), did
require you to set up usernames with Samba, for every user that wanted
to use it.

All in all, it seems easier to ensure that all users have the same ID
numbers on all systems that they use and work with.  Though I'd hate to
have to deal with users who come and go, and use other networks.  They'd
be hard-pressed to apply this solution to more than one network.