VaultKeeper

/vault, /vaults and /pv are wanted by other storage plugins — /pv is PlayerVaults’. Bukkit will not overwrite a name that is already taken: the loser silently gets only its namespaced form, and nothing anywhere says so.

That is the most expensive thing that can go wrong here, because it looks like nothing at all. If /vault reaches a different plugin, every item a player puts away goes into storage VaultKeeper cannot see. There is no error. The first symptom is a player insisting their items vanished — and they have not, they are simply somewhere else.

VaultKeeper takes contested names back from the server and says so in the console at startup. Against another plugin, whoever loads first wins and the server decides that — so if you are keeping another vault plugin, hand it the names in commands.disabled rather than relying on load order. /vaultkeeper commands is the authoritative answer for your server.

One permission node per number: vaultkeeper.vaults.5, vaultkeeper.vaults.15. The highest a player holds wins, so a donor rank stacked on a playtime rank does the obvious thing. vaults.default covers everyone with no node at all, and vaults.max is the ceiling nobody passes.

A wildcard grants no vaults. VaultKeeper reads the numbers out of the nodes a player has actually been granted; it does not test hasPermission for the maximum and work downwards. If it did, anyone holding vaultkeeper.* — which includes every operator — would answer true on the first test and silently receive the ceiling, and nobody would be able to work out why.

To give an administrator 54 vaults, grant vaultkeeper.vaults.54 explicitly.

A donor rank expires, somebody is demoted, or you lower vaults.default — and the player still has items in vault twelve.

VaultKeeper keeps those vaults reachable in withdraw-only mode. They appear in the list with a hopper icon, they open, items can be taken out, and nothing can be put in. Once a vault is empty it disappears from the list by itself.

The player closes it down, not the server. The alternative — hiding the vault and keeping the items — is indistinguishable from theft from where the player is standing, and it produces a support ticket you cannot answer, because the items really are still there. None of this needs configuring; it is simply what happens.

Set storage.type to mysql, point every backend at the same database, and a player’s vaults are the same everywhere. Somebody who opens vault three on survival and walks to skyblock is told “Vault 3 is open on survival. Close it there first.” — naming the server, because “busy” leaves them with nothing they can do about it.

server-id must be DIFFERENT on every server. Two servers sharing one both believe they already hold every lock the other takes, which switches the duplication protection off completely while looking exactly like it is working. It is the one setting worth checking twice; matching your proxy’s server names takes care of it.

There is no connection pool, deliberately. Vault traffic is a handful of statements a minute on async tasks, and a long-lived connection to a database elsewhere on the network is one that eventually gets closed under you by an idle timeout — which surfaces as a broken vault at the worst possible moment rather than as a marginally slower open.

A lock is what makes duplication impossible, so it is also the only thing that can refuse a player — which means you need to be able to see it and clear it. /vaultkeeper locks lists everything held and for how long; /vaultkeeper unlock (player) [number] clears one, or all of theirs.

You will rarely need it. A server clears its own locks the moment it starts, so an ordinary crash-and-restart recovers with no waiting at all. The staleness window (vaults.stale-lock-minutes, 15 by default) only matters for a server that is still down.

unlock refuses while the owner has that vault open on this server, and that refusal is the point: clearing a live lock is precisely how the duplication comes back, because the vault becomes openable in a second window while the first still holds the items.

blocked-items is empty by default — a vault is storage, and you asked for storage. An allowlist would mean every item added to Minecraft is refused until somebody edits a config file.

Entries are either a material name (BEDROCK, COMMAND_BLOCK) or a persistent-data namespace written with a hash (#nexo), which blocks everything a custom-item plugin owns without naming any of it, and without VaultKeeper needing to know that plugin exists. Players with vaultkeeper.bypass.blocked ignore the list.

Anything already stored is never removed and can always be taken back out — the list restricts what goes in and cannot delete what is already there. The filter covers every route an item can take into a vault, not just the obvious one: shift-click from below, a number-key swap from the hotbar, the off-hand swap, and a drag across several slots are four different events, and each has been the hole in somebody’s item filter.

/vaultkeeper open (player) (number) is read-only, and it says so when it opens.

It takes no lock, so it can neither strand one on a player’s vault nor be refused because the owner is using it. The trade is that the view is a snapshot and is never written back.

Every click in that window is cancelled, including taking items out. That is not an oversight: the view is never saved, so an item dragged out of it would exist twice — once in the staff member’s inventory and once still in the owner’s vault.