Content-Type: text/plain; charset=us-ascii
Subject: Re: numeric UIDs
From: David Brodbeck <brodbd@u.washington.edu>
In-Reply-To: <4C6ADC57.80802@excfb.com>
Date: Tue, 17 Aug 2010 13:08:42 -0700
Message-Id: <F8D43B26-2795-4D8A-9429-0DBF0E75031D@u.washington.edu>
References: <201008030401.33552.dreck@vmsd.ath.cx> <20100803192241.GD31579@fieldses.org> <4C6ACB70.7080409@excfb.com> <20100817182400.GE23176@fieldses.org> <4C6ADC57.80802@excfb.com>
To: linux-nfs@vger.kernel.org
Sender: linux-nfs-owner@vger.kernel.org
MIME-Version: 1.0


On Aug 17, 2010, at 12:00 PM, Tom Haynes wrote:

> J. Bruce Fields wrote:
>> 
>> So the server rejects any attempts to set a numeric uid?
>>  
> 
> No, only ones which do not have a valid mapping in /etc/passwd.
> 
>> That means the sort of dumb-backup scenario required above would, as in
>> Linux, succeed over v3, but fail over v4?
>>  
> 
> Yes, it appears so.
> 
>> And have there been reports of users hitting that issue, or does it
>> remain a completely hypothetical problem?
>> 
>> --b.
>>  
> 
> It is all hypothetical. I think you would have to work pretty hard to get a system in such a state.

It comes up pretty regularly when extracting "foreign" tar files on an NFSv4 mount, ones that contain numeric UIDs that don't correspond to a valid user on your system.  You get one error message printed for each file as tar tries to set the numeric UID.  Of course, in that case you can get around it by specifying --no-same-owner, and in most applications it doesn't matter.  It's noticeably different behavior than NFSv3, though.

-- 

David Brodbeck
System Administrator, Linguistics
University of Washington