[Bug 257187] NFSv3 server creates symlinks that local clients can't read [ZFS]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257187

--- Comment #2 from Garrett Wollman <wollman@FreeBSD.org> ---
(In reply to Alan Somers from comment #1)
I get two hits on sdt:zfs::set-error, which I think are actually the same:

dtrace: description 'sdt:zfs::set-error ' matched 1 probe
dtrace: pid 87135 exited with status 1
CPU     ID                    FUNCTION:NAME
 14  47740                   none:set-error 
              zfs.ko`sa_attr_op+0x1b5
              zfs.ko`sa_lookup_uio+0x69
              zfs.ko`zfs_freebsd_readlink+0x7c
              kernel`0xffffffff80b1bf2b
              kernel`vn_rdwr+0x173
              kernel`vn_rdwr+0x26
              kernel`AES_GCM_decrypt+0xa87
              kernel`ssdtosyssd+0x8e

 14  47740                   none:set-error 
              zfs.ko`sa_lookup_uio+0x69
              zfs.ko`zfs_freebsd_readlink+0x7c
              kernel`0xffffffff80b1bf2b
              kernel`vn_rdwr+0x173
              kernel`vn_rdwr+0x26
              kernel`AES_GCM_decrypt+0xa87
              kernel`ssdtosyssd+0x8e

Looks like the only place this can happen is:

                switch (data_op) {
                case SA_LOOKUP:
                        if (bulk[i].sa_addr == NULL)
                                return (SET_ERROR(ENOENT));

which I guess means that zfs_freebsd_readlink() tried to read the ZPL_SYMLINK
attribute and it wasn't found -- but that still doesn't explain how it is that
readlink() succeeds over NFS and not locally.  (A symbolic link is just
uninterpreted text as far as readlink() is concerned, it shouldn't matter what
its value is!)

This indicates a second bug: that [ENOENT] should get transformed into a more
appropriate error on exit to indicate an internal filesystem inconsistency.

-- 
You are receiving this mail because:
You are the assignee for the bug.