Matthias Pfützner <matth...@pfuetzner.de>
writes:
> Harry,
>
> sorry for my first answer, now that you rephrased some of the
> original post, I now remember, what your initial problam really
> was... More inline below...
It may not have been or still may not be much of a clear exposition on
my part either...
[...]
> OK, so that ROOT can chnage things, you need to add options to the
> EXPORT side (aka, the ZFS server)
[...]
> zfs set sharenfs=ro...@192.168.2 pfuetz/smb-share
Thanks for that.
[...]
> You state, that you have the users and groups entries on BOTH
> (client + server) done exactly same by hand, so that should be good,
> still, I would verify that. And also please check on the ZFS-Server
> the file: /etc/nsswitch.conf for the entries for:
>
> passwd
> group
>
> They should look like:
>
> passwd: files
> group: files
>
nisswitch is setup as you've shown
> So, with that knowledge, we need to consult "man share_nfs":
>
> The things interesting to you might be the following options:
>
> anon=uid Set uid to be the effective user ID
> of unknown users. By default,
> unknown users are given the effec-
> tive user ID UID_NOBODY. If uid is
> set to -1, access is denied.
>
> root=access_list Only root users from the hosts
> specified in access_list have root
> access. See access_list below. By
> default, no host has root access, so
> root users are mapped to an
> anonymous user ID (see the anon=uid
> option described above). Netgroups
> can be used if the file system
> shared is using UNIX authentication
> ( AUTH_SYS).
Not really. After more careful reading of share_nfs, mainly as an aid
to working with your posts and info, I'm thinking the defaults should
do just about all I need.
I brought up roots inability on client, to change uid:gid but only
because the defaults appear not to be working. For example:
nosuid
=> By default, clients are allowed to create files on
=> the shared file system with the setuid or setgid
=> mode enabled. Specifying nosuid causes the server
file system to silently ignore any attempt to enable
the setuid or setgid mode bits.
With emphasis on the arrowed lines (not on `nosuid').
Its very possible I'm reading that wrong but it appears to be saying
the client machine users will be able to write files with there own
uid:gid.
That does not occur here. All files are written nobody:nobody
[...]
>> And again, the USER:GID exists on both server and client with
>> the same numeric uid:gid:
>>
>> osol (server) host:
>>
>> uname -a
>> SunOS zfs 5.11 snv_133 i86pc i386 i86pc Solaris
>>
>> root # ls -lnd /export/home/reader
>> drwxr-xr-x 60 1000 10 173 2010-03-11 12:13 /export/home/reader
On closer checking I see the above info is erroneous/.
> Which "ls" command? /usr/gnu/bin/ls, or /usr/bin/ls? Still: Here we see, that
> the file had been created by a user with User-ID: 1000 and Group-ID: 10.
A default osol install leaves gnu tools first in the path so it was
gnu `ls' I posted.
>
> What's the output of:
>
> ls -ld /export/home/reader
>
> Does that resolve and list the user-name and group-name?
yes, well no.
I've found what may explain some of this... it appears somewhere in
the last few updates on client... my carefully hand edited gid has
disappeared.
There was a point whereas neither users default gid matched but each
belonged to group `wheel', which had been hand edited to match.
So there was a shared gid on both ends. That is no longer the case.
Not sure why.
But even then the share_nfs man page seems to indicate that the client
users will write files to there own gid (there is no mention of
matching gid on both ends)
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
