I have a server (T5220, though I doubt it matters) running Solaris 10 8/07 and I have a ZFS pool, "mysql", on internal disk. Within it I have a filesystem "mysql/data/4.1.12", which I snapshot hourly with a script from cron.

I have one snapshot, created as one of those hourly snaps, that will not destroy. I have renamed it out of sequence to be "mysql/data/4.1.12@wibble" so that my script will not try and fail to destroy it, but it was originally within the sequence, though I doubt that matters. It renames successfully. The snapshot can be successfully navigated and read from through the .zfs/snapshots directory. It has no clones based on it.

Trying to destroy it does this:

(265) root@web-mysql4:/# zfs destroy mysql/data/4.1.12@wibble
cannot destroy 'mysql/data/4.1.12@wibble': dataset already exists
(266) root@web-mysql4:/# 

which is apparently nonsensical: of course it already exists, that's the point!

Anyone seen anything like this before? Web searches show nothing obviously similar.

I can provide patches installed if necessary.


This issue has now been answered, courtesy of Cindy Swearingen (cindys) here: http://opensolaris.org/jive/thread.jspa?messageID=484242&tstart=0

Summary: If you do incremental receives, this might be CR 6860996:

A temporary clone is created for an incremental receive and in some cases, is not removed automatically.

1. Determine clone names:

# zdb -d <poolname> | grep %

2. Destroy identified clones:

# zfs destroy <clone-with-%-in-the-name>

It will complain that 'dataset does not exist', but you can check
again(see 1)

3. Destroy snapshot(s) that could not be destroyed previously

After having upgraded to more recent patch sets, I could delete this snapshot successfully. Clearly was a bug somewhere that Sun squashed.


Whilst this solution is probably unrelated to the OP's issue, I also had this same cryptic error message when trying to delete a zvol.

In my case, the zvol had been created by an interrupted zfs receive, which was sent using the "-s" resumable feature. The resume token was preventing it from being destroyed.

To fix it, I ran zfs receive -A <pool/zvol> (on FreeBSD 10.3)

  • Useful to know; it's certainly possible this was the case. – Morven Jan 11 '17 at 20:01

I don't expect this is the issue (I think you get a different error message), but do you have any clones based on that snapshot?

  • No clones based on it; that's what I suspected at first, but that's not it. – Morven Sep 17 '09 at 21:31

I have also seen this problem (nov 2009). Again just ONE snapshot can not be destroyed and I get the same nonsensical message

# zfs destroy blue/viss02_backup/46home1f@200910211357
cannot destroy 'blue/viss02_backup/46home1f@200910211357': dataset already exists

And this snapshot is not the origin for and filesystem clone. In fact I have one cloned filesystem - but a recursive search shows that it is not based on the troublesome snapshot

# zfs get -H -o value -r origin blue | uniq

Until I rename it this snapshot will also screw up the scripts which I run to control the proliferation of snapshots.

Version information: This is Solaris on x86 (5.10 Generic_141445-09 i86pc) This system is currently running ZFS pool version 15. All pools are formatted using this version.


Same problem without any clone.

The problems occurs while the zfs version was 10. We try to upgrade to 15 without any changes

 zfs destroy -rR zpool/mailboxes
 cannot destroy 'zpool/mailboxes@bug': dataset already exists


I ran into this long ago and wrote here: http://www.bitshop.com/Blogs/tabid/95/EntryId/101/ZFS-Destroy-dataset-does-not-exist-zdb-error-16.aspx

However this time isn't a % related issue. I'm on Illumus / Illumian 1.0, which is zpool version 26.

This is a very old server/snapshot I'm trying to delete.


Try looking at the dataset with zdb.

zdb -e -d tank

I was trying to do

zfs destroy -r tank/dataset

which shows up on zfs list and was getting this error.

What I found was that zdb saw


which was not showing up on zfs list. I was able to easily

zfs destroy -r tank/dataset/dataset

and then

zfs destroy -r tank/dataset

with no errors.

This seems like maybe a bug in zfs list. FreeBSD 11.2-STABLE.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.