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

Everything is so close to working with only Kerberos/AD... It is too bad
that LDAP is still required for full integration.


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

Reply via email to