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 <judahrichard...@gmail.com> wrote: > > > On Tue, May 4, 2021 at 5:53 PM Alan Coopersmith < > alan.coopersm...@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- >> > _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss