[clue] NFS uids? (FreeBSD/Gentoo)

[foo7775 at comcast.net]

I'll second Chris' suggestion to look at (use?) the 'usermod' command. If memory serves, I was able to resolve a couple of similar problems that way. 

Good luck. 

T. 

----- Original Message -----

From: "Chris Fedde" <chris at fedde.us> 
To: Yaverot at computermail.net, "CLUE's mailing list" <clue at cluedenver.org> 
Sent: Tuesday, March 15, 2016 12:58:21 PM 
Subject: Re: [clue] NFS uids? (FreeBSD/Gentoo) 

Changing the UID/GID to be consistent across the nfs clients is probably the best plan. 
You might want to consider using the usermod (1) command to do the heavy lifting here. 
Look especially at the -u and -g options. 

If you have several clients then maybe you want to script the work. For very casual multi-host things I might use ssh in a loop or pssh. 
I'm also a fan of ansible for managing config across a community of systems but front loading this task with that learning might be too much. 

chris 






On Tue, Mar 15, 2016 at 1:57 AM, Yaverot < Yaverot at computermail.net > wrote: 


I'm finally making the transition away from my home OpenSolaris fileserver which I setup apparently in June 2009. 
The new system is FreeBSD 10.2 
I've successfully done a zfs send of all the data from the old server. Now I'm trying to set up sharing from it. 
I'm also taking this opportunity to switch from cifs/samba to NFS(4), since neither is the "just flip the magic switch" on any open source operating system, but NFS is supposedly easier "once you've done it right the first time". 

So I believe I'm now getting a "successful" mount, but can't read anything due to uid/gid mismatch. It could still be something else, but the mount command is not coming back with failures anymore. 
On the old fileserver, the shared data was all written yaverot:yaverot (501:501), so it was received as 501:501 on the new server. 
On the new server I created default ids and everything in the home folder is yaverot:yaverot (1001:1001) - the only data of value attached to this user is its ~/.ssh/ and that it is part of wheel. 

for my clients (running Gentoo) 
yaverot:users (1000,100) 
luckily, it appears they're all the same 

So I'm looking for the easiest/simplest solution that will work. I think it is changing my user on the new server to be 501:501 and then allow NFSv4 to do conversion like it supposedly does is easiest, which will work when the system knows the "correct" uid/gid for my user. But I don't know if that feature actually works. 

Second best solution is to see if there's some setting I could put on the zfs recv such that it writes the uid/gid for the existing user on the system instead of the one in the stream and redo the two-day send/recv. I doubt such a thing exists. Obviously, I can't simply chown the live data to the uid/gid given on the new server as that wouldn't also update the snapshots (making them worthless). 

Third best I think is figuring out samba, since this wasn't a problem at all with it - just that the server was stuck at a version of the protocol that's now considered obsolete. (As well as other obsolete versions, like openssh) I've just heard it is hard compared to NFS. 

--- 
Assuming my first idea is best, do I fix the uid/gid by editing /etc/passwd then doing a recursive chown on its home directory; or do I rename the user (3 files in /etc ?), and create a new user with the correct uid/gid? 
_______________________________________________ 
clue mailing list: clue at cluedenver.org 
For information, account preferences, or to unsubscribe see: 
http://cluedenver.org/mailman/listinfo/clue 





_______________________________________________ 
clue mailing list: clue at cluedenver.org 
For information, account preferences, or to unsubscribe see: 
http://cluedenver.org/mailman/listinfo/clue 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cluedenver.org/pipermail/clue/attachments/20160315/330c1207/attachment-0001.html