Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

This issue has now been answered, courtesy of Cindy Swearingen (cindys) here:

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
share|improve this answer
This fixed a similar issue for me. Thanks! – sh-beta Mar 5 '12 at 17:27
up vote 2 down vote accepted

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

share|improve this answer

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?

share|improve this answer
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.

share|improve this answer

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

share|improve this answer

I ran into this long ago and wrote here:

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.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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