Cannot delete a dataset — it says the dataset is busy or has dependents, and I cannot find what is holding it

The one that gets me every time is the stopped virtual machine.

The VM is off, so mentally it does not exist, but its disk definition still references the dataset and the system will not let go. Same for a container that is stopped but not removed — the mount is part of the definition, not the running state.

So when you go looking, look at defined objects, not running ones. Anything in the system that has ever been pointed at that path and has not been deleted.

Second one, less obvious: a replication task with that dataset as its source. Even a disabled task keeps the reference and can be what placed a hold.

Good instinct not to reach for force. There are exactly two families of cause here and they need different answers, so first work out which one you have — the wording is the clue.

"Busy" means something has it open. The filesystem cannot be unmounted because a process has a file or a working directory inside it. Usual suspects, roughly in order of how often it turns out to be them:

• a container or virtual machine with the path mounted, including a stopped one whose mount definition still exists
• a network share still configured for that path, even if no client is connected
• a shell somebody left sitting in that directory — including your own, in another terminal
• a scheduled task, a backup job or a scan that happens to be running right now
• an NFS export still published

The direct way to find it is to ask the system which processes hold files open under that mountpoint; there is a standard tool for exactly that. That usually names the culprit in one line. If it comes back empty and the unmount still fails, look at share and export definitions rather than processes, because a configured share holds the path without any process obviously owning it.

"Has dependents" is a completely different thing and force will not help you. It means something is derived from this dataset:

• Snapshots. Deleting a dataset means deleting its snapshots, and depending on how you are asking, the system wants that made explicit.
• Clones. This is the important one. A clone is a writable dataset created from a snapshot, and it shares blocks with the original. The original cannot be destroyed while a clone depends on it, because the clone's data is partly the original's data. This is not a lock you can override, it is the storage layer refusing to delete data that something else is still using.
• Holds. An explicit tag placed on a snapshot to prevent deletion, usually by a replication or backup task, sometimes left behind when such a task was interrupted.

Dealing with a clone properly. You do not delete the parent. You promote the clone, which swaps the dependency relationship so the clone becomes the independent dataset and the original becomes the dependent one. Then the original can be destroyed. No data moves and nothing is copied — it is a bookkeeping change.

If you do not want the clone either, destroy the clone first and then the parent, in that order.

Holds have to be released by name before the snapshot will go. List the holds on the snapshots involved and you will see which task put them there, which is often the more interesting piece of information.

What force actually does, since you asked: it will forcibly unmount a busy filesystem out from under whatever is using it. If that is a running database or a virtual machine's disk, you have just pulled the floor out from under it mid-write. It does not override clone dependencies, so for the second family it will not even work.

Practical shortcut for finding clones: ask the storage layer to list every dataset along with its origin property. Anything whose origin is a snapshot of the dataset you are trying to delete is a clone of it, and now you have the name.

That one query answers "what depends on this" definitively, without guessing from the UI. Worth knowing before you need it.

Before you delete anything: if this really was an experiment, take one snapshot of it and put a retention date in your calendar for a month out.

A snapshot of an idle dataset costs nothing in space, and "I deleted the experiment and then needed one file from it" is a specific kind of annoying that is entirely avoidable for zero effort.