|Eric Lucas on 27 Feb 2013 13:08:56 -0800|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: [PLUG] nfs question|
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 <email@example.com> 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".
and google for:
nfs root squash
=> > 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