On 08/30/11 14:50, Marc Bevand wrote:
It did not work.
No matter what nfsmapid_domain is set to (any-other-name.com or
example.com), files created on the ZFS file system by my Kerberized
NFSv4 client always end up owned by nobody. I even rebooted the Solaris
server and the client after each change to make sure I did not forget to
reload a service, or was not accidentally re-using cached data
somewhere.
Everything is so close to working with only Kerberos/AD... It is too bad
that LDAP is still required for full integration.
Foo.
One of the big problems that we have in this area is that there are so many
things that have to be configured just right for everything to work that
there are many ways to fail. Some components have diagnostic information
that can help, while others don't.
I don't know exactly when Solaris 11 Express was in terms of our internal
build numbers, and so I don't know whether you have the current idmap
diagnostic features. Try "idmap show -cV uid:0" I'm not interested in the
output, just in whether it complains about the V.
If it doesn't complain about the V, try this:
# svccfg -s idmap setprop debug/mapping = 2
# svcadm refresh idmap
and then
# tail -f /var/svc/log/system-idmap:default.log
while you log in and create a file.
If the NFSv4 parts of the system are running right, you should see trace
results from mapping the name@domain that NFSv4 carries over to a (possibly
ephemeral) UID. If you don't get any trace results, that's interesting.
If you *do* get trace results, they may help to explain the problem.
Unfortunately, there's no similar tracing capability in the NFSv4 part of
the picture.
When you're done, do
# svccfg -s idmap setprop debug/mapping = 0
# svcadm refresh idmap
to turn the output back off.
_______________________________________________
cifs-discuss mailing list
cifs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
