> 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
