Hi all, I'm new to OpenSolaris (5 days, Linux: ~10 years), and am trying to evaluate ZFS and NFSv4 in the process to see if we can use it to replace a couple of Linux-based file servers.
OpenSolaris version: SunOS opensolaris 5.11 snv_86 i86pc i386 i86pc (200805) Linux: Debian 4.0 (etch) w/kernel 2.6.22.14 Share config: root at opensolaris:~# share - at nfs /export/rz2-zfs anon=-1,sec=sys,ro...@172.16.4/24 "raid-z2 nfs share" I believe I've set up idmapd.conf and /etc/default/nfs correctly on the respective boxes, both have "bofh.net.au" specified as their domain. The Linux box is mounting an NFS share from the OpenSolaris box, like so: mount -t nfs4 -o sec=sys opensolaris.bofh.net.au:/export/rz2-zfs /mnt/media1 I can (as root) create a new file in /mnt/media1 from the Linux box without a problem, it has the correct ownership (root:root). When the following command is issued, it fails, and I believe I understand why but I have no idea how to work around the problem: holywars:~# chown 123:456 /mnt/media1/foo chown: changing ownership of `/mnt/media1/foo': Invalid argument yet: holywars:~# chown 101:10 /mnt/media1/foo holywars:~# works as expected. A user with UID 101 exists in /etc/passwd on the OpenSolaris box, as does a group with GID 10, same applies to the linux client. A snoop running while the above command is executed shows the following: 172.16.4.76 -> 172.16.4.82 NFS C 4 () PUTFH FH=5A0A ACCESS rd,lk,mo,ext,dl 172.16.4.82 -> 172.16.4.76 NFS R 4 () NFS4_OK PUTFH NFS4_OK ACCESS NFS4_OK Supp=rd,lk,mo,ext,dl Allow=rd,lk,mo,ext,dl 172.16.4.76 -> 172.16.4.82 TCP D=2049 S=767 Ack=3517170495 Seq=3477020292 Len=0 Win=242 Options=<nop,nop,tstamp 5942903 10235851> 172.16.4.76 -> 172.16.4.82 NFS C 4 () PUTFH FH=5A0A GETATTR 10011a 30a23a 172.16.4.82 -> 172.16.4.76 NFS R 4 () NFS4_OK PUTFH NFS4_OK GETATTR NFS4_OK 172.16.4.76 -> 172.16.4.82 NFS C 4 () PUTFH FH=5A0A LOOKUP foo GETFH GETATTR 10011a 30a23a 172.16.4.82 -> 172.16.4.76 NFS R 4 () NFS4_OK PUTFH NFS4_OK LOOKUP NFS4_OK GETFH NFS4_OK FH=6A58 GETATTR NFS4_OK 172.16.4.76 -> 172.16.4.82 NFS C 4 () PUTFH FH=6A58 SETATTR ST=SPC0 GETATTR 10011a 30a23a 172.16.4.82 -> 172.16.4.76 NFS R 4 () NFS4ERR_BADOWNER PUTFH NFS4_OK SETATTR 0 0 172.16.4.76 -> 172.16.4.82 TCP D=2049 S=767 Ack=3517171051 Seq=3477020812 Len=0 Win=276 Options=<nop,nop,tstamp 5942914 10235851> The Linux client is 172.16.4.76, the OpenSolaris box is 172.16.4.82 My experiments seem to show that if there is a user and a group on the linux client and a user and group of the same name on the OpenSolaris box, that I'll be able to chown the file without a problem, but when this isn't the case it gives the NFS4ERR_BADOWNER error. I think thats because the linux client is mapping the UID to a username, and the GID to a group name on the local machine, then telling the OpenSolaris box to set the ownership of the file to those names. When the OpenSolaris id mapper consults /etc/passwd, it can't find one or the other (or both) and fails. So if thats correct, then is there any way to take UID/GID mapping out of the picture and just use stringified UIDs and GIDs over the network (which I read is not recommended, but I don't know that I have any choice in the matter considering what I want to do). My goal here is to test the viability of having say 30 Linux virtual server file systems exported from the NFSv4 share on the OpenSolaris box. These virtual servers will all have different users and groups, and I seem to need the NFS server not to care about being able to map the UIDs/GIDs to local accounts/groups. Using NFSv3 instead of v4 seems to work, but if possible I'd prefer to get NFSv4 going. Any hints? -- Regards, Robert Davidson. Obsidian Consulting Group. Ph. 03-9355-7844 E-Mail: support at obsidian.com.au
