Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Jul 2021 00:03:46 +0000
From:      bugzilla-noreply@freebsd.org
To:        fs@FreeBSD.org
Subject:   [Bug 257187] NFSv3 server creates symlinks that local clients can't read [ZFS]
Message-ID:  <bug-257187-3630-uZizdrBQbO@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-257187-3630@https.bugs.freebsd.org/bugzilla/>
References:  <bug-257187-3630@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D257187

--- 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=20
              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=20
              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 =3D=3D NULL)
                                return (SET_ERROR(ENOENT));

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

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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-257187-3630-uZizdrBQbO>