Eric Lucas on 27 Feb 2013 13:32:08 -0800


[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

Re: [PLUG] nfs question


Further testing: Now it just works.

Might have been some latency in the permissions for nfs?  I umounted and mounted it after changing it on the server but I then tested it immediately and got the error.

Maybe I'm just impatient? 

Eric

On Wed, Feb 27, 2013 at 4:09 PM, Eric Lucas <eric@lucii.org> wrote:
Oh, I spoke too soon. 
If I do this:
   touch testfile 
then testfile is owned by root.
if I do (as root):
   ufsdump -0uLF boot  /destination/sample-boot /boot 
then the file is owned by 65534 again.  
Then, between pass II  and pass III of the ufsdump processing it carps that it's 
an unsupported condition.

As a test, I went to the Linux server and typed chown root:root /destination/sample-boot
and then told ufsdump to continue (it was prompting for 'yes' or 'no').
ufsdump finished normally.

Jeez, this is tough!
Any thoughts?

Eric



On Wed, Feb 27, 2013 at 3:58 PM, Eric Lucas <eric@lucii.org> wrote:
Ah yes... no_root_squash did the trick!  Thanks everybody.

Eric

On Wed, Feb 27, 2013 at 3:19 PM, <bergman@merctech.com> wrote:


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



___________________________________________________________________________
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