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.