Greetings,
I was attempting to access/manage ZFS snapshots from a MacOSX NFSv4
client and have discovered a couple bugs/issues:
(1) Attempts to request the FATTR4_NAMED_ATTR attribute on the ".zfs"
directory and any immediate subdirectories causes the GETATTR operation
to return NFS4ERR_INVAL. The same GETATTR operation with that attribute
ommitted succeeds. Seeing as how this attribute is technically a
"mandatory" attribute... I don't think EINVAL is a fair response. :-)
If the attribute is not supported on those directories, I would suggest
simply not returning that attribute.
(2) ACCESS operations on the ".zfs/snapshot" directory and the snapshot
subdirectories erroneously report that the user is not allowed to create
or delete snapshot directories even though the user does have the
permissions to perform those operations - and performing such operations
succeeds. This happens for a normal user that has delegated authority to
perform those operations and also for the root user when root is mapped
to root on the server. (This also affects NFSv3.)
If necessary, I can provide a packet capture file demonstrating these issues.
I have not attempted to dig through the OpenSolaris NFS/ZFS code to try to
track either of these problems down myself.
The FATTR4_NAMED_ATTR test has the simple workaround of not asking for
that attribute. However, the MacOSX NFS client plans on making extensive
use of named attributes for natively storing extended metadata. Working
around the problem by having the client not ask for that attribute on
only the ".zfs" directory and its subdirectories will not be a
simple/localized change.
The ACCESS reporting issue is a problem when the NFS client('s VFS layer)
preflights operations before attempting them. And, yes, unfortunately
MacOSX is affected by this and this means the client will not even attempt
to create/delete snapshots even though the operations would succeed.
Like the first problem, working around this in the client will not be simple.
Needless to say, I'd prefer if these issues were fixed on the server so
there would at least be hope that someday any workarounds in the client
would no longer be necessary.
Thanks for any help.
--macko
Apple NFS Engineer
