Re: [PLUG] nfs question

[bergman@merctech.com]

In the message dated: Wed, 27 Feb 2013 14:39:25 -0500,
The pithy ruminations from Brad on 
<Re: [PLUG] nfs question> were:
=> I ran into this moving an nfs server on a solaris host, and found that both
=> need nfs server and nfs clients need to be configured to use
=> /etc/idmapd.conf, and that file should have the same domain so the
=> uids/gids work on both, otherwise they default to the nobody/nogroup.

Yes, but not for root.

=> 
=> 
=> On Wed, Feb 27, 2013 at 2:32 PM, Eric Lucas <eric@lucii.org> wrote:
=> 
=> > I've heard admins gripe about nfs for years but I'd never tried it...
=> > until today!
=> >
=> > 1. Linux box runs Red Hat and exports a share called dropbox
=> > 2. Sun Blade 2500 mounts 192.168.100.5:/dropbox on mountpoint /dropbox.
=> >
=> > So, when the root user on the Sun saves a file to the /dropbox the
                  ^^^^^^^^^^^^^^^^^^^^

Don't do that. :)

=> > ownership
=> > changes to 65534 (nobody) and the group to 65534 (nogroup)

What you're seeing is normal, deliberate, well-documented behavior.

By default, in the absence of intentionally making No F*scking Security even
less secure, NFS will remap files owned by "root" to user "nobody".

Do:
	man exports
	man mount

and google for:

	nfs root squash


Mark

=> >
=> > It all *appears* to run normally so I'm at a loss to know why UID of 0 on
=> > both
=> > sides gets mis-matched or changed on the fly.
=> >
=> > Thanks,
=> > Eric
=> >
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug