Harry,
all very bizarre... ;-)
You (Harry Putnam) wrote:
> 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're welcome!
> > 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.
Agreed! Accept, possibly, if needed, the "root" option might be handy...
> 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').
Right!
> 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.
Right!
> That does not occur here. All files are written nobody:nobody
Strange!
> [...]
>
> >> 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/.
Even stranger... ;-)
> > 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.
Right! I only asked, because, if you would be using "sharesmb" also, then
files created via Windows Servers will be nobody:nobody regardless, and all
"access info" is captured in ACLs, and gnu ls simply does not show these
ACLs... You need the Solaris native "ls" to see them...
> > 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.
Strange! I don't know of any automated tool, that would edit either
/etc/passwd or /etc/group...
> 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)
You're right again!
Back to NVS v4 vs. v3. I've no idea, on how Linux does define the version, you
mentioned, it's been done in a config file, and that you did set that to be
v3.
Are you sure, that the Linux box does HONOUR that setting? Or might it be the
case, that that is ignored, (perhaps root or daemon or ... can't read it at
boot time)
On Solaris, you would force that in /etc/default/nfs (see "man nfs"), still,
that file needs to be readable at boot time:
[sr1-efra05-04: home/pfuetz] {1310} % ls -al /etc/default/nfs
-rw-r--r-- 1 root root 2870 May 15 2009 /etc/default/nfs
[sr1-efra05-04: home/pfuetz] {1311} %
Still, all very strange!
Matthias
--
Matthias Pfützner | Tel.: +49 700 PFUETZNER | I'm not holding my breath
Lichtenbergstr.73 | mailto:matth...@pfuetzner.de | for reliable voice
D-64289 Darmstadt | AIM: pfuetz, ICQ: 300967487 | recognition.
Germany | http://www.pfuetzner.de/matthias/ | Ted Nelson
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
