> hi folks,
>
> i''m seeing an odd problem & wondered whether others
> had encountered it.
>
> when i try to write to a nevada NFS share from a mac
> os X (10.5) client via the mac''s GUI, i get a
> permissions error - the file is 0 bytes, date set to
> jan 1, 1970, and perms set to 000. writing to the
> share via the command line works fine, so it''s not a
> "normal" permissions problem.
>
> here''s the weird thing:
>
> a) with mac os X 10.4, sparc snv_84 and zfs
> filesystem zhared via NFS => no problem
>
> b) mac os X 10.5, sparc snv_84, zfs => doesn''t work
>
> c) mac os X 10.5, sparc snv_84, UFS => no problem
>
> d) mac os X 10.5, x86 snv_115, ZFS => no problem
>
> e) mac os X, 10.5, sparc snv_125, ZFS => doesn''t
> work
>
> i haven''t yet tried sparc snv_125 + UFS, but i''m
> wondering if there''s anyone out here with a working
> combination of: mac os X 10.5, sparc snv_120+, ZFS,
> NFS ?
>
> i thought at first it was a problem with the mac 10.5
> nfs client, but then i''d expect (c) and (d) to fail,
> too.
>
> i''ve tried existing shares, new shares, zfs-based
> sharing, straight "share(1m)" sharing,
> root=mac_client - none have made much difference.
> it''s all been NFSv3
>
> snooping the communication hasn''t yielded much
> obvious.
>
> any thoughts/suggestions/wisdom?
following up on this, i can confirm the following:
x64, zfs, snv_126 = ok
sparc, zfs, snv_125 = fail
sparc, ufs, snv_125 = ok
thanks for the help offered so far; i''ve been shown the following by
macko:
[...]
OK, it looks like e_nfs_gui has the failure case and it is failing
because the server for some reason is not correctly setting the
mode of the new file when it is created exclusively.
At Packet #87, we see an exclusive CREATE of pwl_standard.jpg
followed immediately with a SETATTR call (#94) that specifies the new
file''s mode should be 0644. In packet #95, the server reports that
the SETATTR call succeeded, but the new attributes returned for the
file show that the mode is still 0000. And subsequent ACCESS requests
on that file report that no access is allowed.
The same thing happens again starting at packet #188, but in that case
the mode being set is 0666. But the result is the same, the server reports
that the SETATTR succeeds but the attributes show that the mode is still
set to 0000.
In e_nfs_cli and n_nfs_cli, the CREATE attempt is not done exclusively
and the problem does not happen. The non-exclusive (unchecked) create
succeeds and the mode is set to the mode passed in the CREATE call.
In n_nfs_gui, the CREATE attempt is done exclusively like in e_nfs_gui
however the client''s attempt to set the mode via SETATTR does succeed
and the new attributes show the new mode.
The difference between e_nfs_gui and n_nfs_gui appears to be in the
NFS server''s handling of the SETATTR request that follows the exclusive
CREATE request.
The client attempts to set mode=0644, uid=36493, and gid=0.
The gid=0 is because the directory''s gid=0 and the Mac VFS layer
considers the default behavior to be to copy the directory''s gid to
the child. Some servers may balk at this if the credential isn''t a
member of the group, but the Mac NFS client will then attempt the
SETATTR again without setting the uid/gid. This is what happens in
n_nfs_gui.
Strangely, in the e_nfs_gui trace the SETATTR request does appear to
set the gid=0 successfully even though the mode seems unchanged.
[...]
so - something weird is happening when an nfs call is made on a zfs filesystem
to do exclusive create & setattr
given the places where this succeeds & fails, this is starting to look like
a zfs (sparc) bug - but i''m happy to be shown that it''s some
sort of global settings problem instead.
any further suggestions? i can provide snoops/tcpdumps if anyone is
interested.
--
This message posted from opensolaris.org