Recursive destroy of zfs snapshot fails on non-existing target snapshot
Prior to revision 11314 if a user was recursively destroying snapshots of a dataset the target dataset was not required to exist.
The zfs_secpolicy_destroy_snaps() function introduced the security check on the target dataset, so since then if the target dataset does not exist, the recursive destroy is not performed. Before 11314, only a delete permission check on the snapshot's master dataset was performed.
Steps to reproduce:
zfs create pool/a
zfs snapshot pool/a@s1
zfs destroy -r pool@s1
Therefore I suggest to fallback to the old security check, if the target snapshot does not exist and continue with the destroy.
Updated by Martin Matuška over 9 years ago
The failure described in this bug depends on the existence of the top-level snapshot (the snapshot specified as argument) and not on the user calling the command. The manpage for "zfs destroy [-rRd] snapshot" says:
Destroy (or mark for deferred deletion) all
snapshots with this name in descendent file systems.
So this should not depend on the existence of the snapshot specified in name (e.g. rpool/test@s1 doesn't have to exist to recursively destroy all @s1 snapshots in the hierarchy under rpool/test, e.g. the snapshot rpool/test/a@s1).
# uname -a SunOS db6 5.11 oi_151a i86pc i386 i86pc Solaris # whoami root # zfs create rpool/test # zfs create rpool/test/a # zfs snapshot rpool/test/a@s1 # zfs destroy -r rpool/test@s1 cannot destroy 'rpool/test@s1': dataset does not exist no snapshots destroyed # zfs snapshot rpool/test@s1 # zfs destroy -r rpool/test@s1