[OpenIndiana-discuss] Which OI service cleans up hidden NFS files?

[Judah Richardson]

Extremely stupid question: is the fact that those mounted locations contain
ZFS snapshots resulting from znapzend's underlying use of zfs send & receive
and not actual physical directories possibly why find, cd, etc. can't reach
them?

Shooting in the dark here; that's the only thing I can come up with.

On Tue, May 4, 2021 at 6:15 PM Judah Richardson <judahrichardson at gmail.com>
wrote:

>
>
> On Tue, May 4, 2021 at 5:53 PM Alan Coopersmith <
> alan.coopersmith at oracle.com> wrote:
>
>> On 5/4/21 3:38 PM, Judah Richardson wrote:
>> > I did some searching about the error message and found this Solaris
>> > documentation page
>> > <https://docs.oracle.com/cd/E37838_01/html/E61004/gqmry.html> about
>> > removing hidden NFS files. It says that the above error is due to
>> something
>> > called nfsfind, but that nfsfind should be superseded by a service
>> called
>> > svc:/network/nfs/cleanup.
>>
>> It also says that the nfs cleanup service was added in Solaris 11.4,
>> which is
>> much newer than the pre-Solaris-11.0 base that OpenIndiana/illumos is
>> based on.
>>
> Good point. I'm often not sure how closely OI tracks Solaris in one thing
> or the other, which is why I ask questions.
>
>>
>> Don't you still have the nfsfind command in your root crontab?
>>
>>
>> https://github.com/illumos/illumos-gate/blob/9ecd05bdc59e4a1091c51ce68cce2028d5ba6fd1/usr/src/cmd/Adm/root#L30
>
> Yes I do.
>
> I think I found the problem, but I can't explain why it's happening. The
> directories in question are mounted:
>
> $ mount | grep znapzend
> /znapzend on rpool1/znapzend
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10008 on Fri Apr
> 30 21:59:04 2021
> /znapzend/DellOptiPlex390MT on rpool1/znapzend/DellOptiPlex390MT
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10034 on Sat May
> 1 10:00:03 2021
> /znapzend/DellOptiPlex390MT/ROOT on rpool1/znapzend/DellOptiPlex390MT/ROOT
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003a on Sat May
> 1 10:00:04 2021
> /znapzend/DellOptiPlex390MT/ROOT/openindiana on
> rpool1/znapzend/DellOptiPlex390MT/ROOT/openindiana
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003c on Sat May
> 1 10:03:00 2021
> /znapzend/DellOptiPlex390MT/export on
> rpool1/znapzend/DellOptiPlex390MT/export
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003d on Sat May
> 1 10:03:22 2021
> /znapzend/DellOptiPlex390MT/export/home on
> rpool1/znapzend/DellOptiPlex390MT/export/home
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10040 on Sat May
> 1 10:03:33 2021
> /znapzend/DellOptiPlex390MT/export/home/judah on
> rpool1/znapzend/DellOptiPlex390MT/export/home/judah
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10042 on Sat May
> 1 10:03:48 2021
>
> But I can't navigate to them, and so neither can the find $dir -type f
> -name .nfs command in the nfsfind script:
>
> $ cd /znapzend/DellOptiPlex390MT/ROOT/openindiana
> -bash: cd: /znapzend/DellOptiPlex390MT/ROOT/openindiana: No such file or
> directory
>
> # find /znapzend/DellOptiPlex390MT/ROOT/openindiana -type f -name .nfs
> find: ‘/znapzend/DellOptiPlex390MT/ROOT/openindiana’: No such file or
> directory
>
> I'm reasonably sure there's something obvious here I'm missing.
>
> Is it possible that znapzend makes destination filesystems unreachable to
> prevent them from being tampered with? What would I check for to see if
> this is the case?
>
>
>>
>>         -alan-
>>
>