Using a custom music disc pack on a Minecraft server

Server packs vs. local installs

A resource pack installed through the in-game menu lives on one machine. Nobody else on the server hears your custom discs, and you hear them even in single-player worlds where they may make no sense.

A server resource pack flips that around. The server advertises a pack when a player connects, the client downloads and caches it, and it stays applied for as long as they are on that server. Nothing is installed permanently, and the pack applies to everyone the same way — which is the only sane option if custom discs are part of how your world actually plays.

Important consequence: the server does not send the file. It sends a URL, and each client downloads from there itself. Hosting the file is your job, and it is where most of the difficulty lives.

Java Edition: the server.properties keys

Stop the server before editing server.properties — it is rewritten on shutdown and will overwrite your changes otherwise. The keys that matter:

resource-pack=https://example.com/packs/my-discs.zip
resource-pack-sha1=6f1ed002ab5595859014ebf0951522d9f0b8e4f2
require-resource-pack=false
resource-pack-prompt=Custom music discs for this server

• resource-pack — a direct HTTPS download URL for the .zip. Not a web page that has a download button on it; the actual file.
• resource-pack-sha1 — the SHA-1 hash of that exact zip. Technically optional, practically mandatory; see below.
• require-resource-pack — when true, a player who declines the prompt is disconnected. When false (the default) they play on with vanilla disc audio.
• resource-pack-prompt — the message shown on the accept/decline screen. Plain text works; it also accepts a raw JSON text component if you want formatting.

Restart the server after saving. Players already connected will not be re-prompted — they need to reconnect.

Why the SHA-1 hash matters more than it looks

The hash is how the client knows whether the copy in its cache is still current. Get it right and players download the pack once, then join instantly forever after. Get it wrong and you hit one of two annoying failure modes:

• Omitted entirely — clients cannot verify the cache, so many will re-download the whole pack on every single join. On a music pack that is megabytes per player per connection.
• Stale after an update — you upload a new zip but leave the old hash in place. Clients compare, decide their cached copy matches what the server asked for, and keep serving the old audio. This is far and away the most common “my changes aren't showing up” report.

Generate it from the exact file you uploaded, not from an earlier build:

# macOS / Linux
shasum -a 1 my-discs.zip

# Windows (PowerShell)
Get-FileHash -Algorithm SHA1 my-discs.zip

Paste the hex digest in lowercase with no spaces. Re-hash and update the key every time you re-upload the pack — treat it as part of the deploy, not an afterthought.

Hosting the file: what counts as a direct URL

The client performs a plain HTTP GET and expects the zip bytes back. Anything that answers with an HTML interstitial, a consent screen, or a redirect chain to one will fail.

Generally works: object storage with public read (S3, R2, Backblaze B2, Spaces), a static file on any web server you control, GitHub Releases asset URLs, or a file drop that documents a genuine direct-download endpoint.

Generally does not: a Google Drive sharing link, a normal Dropbox share link (the ?dl=0 form serves a preview page — the ?dl=1 form is the one that returns the file), MediaFire and similar ad-gated hosts, or anything behind a login.

Test before you trust it. From a machine that is not your server, with no cookies or session in play:

curl -IL https://example.com/packs/my-discs.zip

You want a final 200 with content-type: application/zip and a content-length matching your file. If you see text/html, the client will download a web page, fail to unzip it, and report a broken pack.

Keep the file small while you are at it. Audio is essentially all of a music disc pack's weight, every player pays the download, and Minecraft enforces a server-pack size limit that has varied by version. A handful of tracks is fine; twenty long, high-bitrate ones will cause problems. The mono OGG guide covers how the encoding settings affect size.

Should you require the pack?

Setting require-resource-pack=true keeps everyone in sync — nobody is standing next to a jukebox hearing something different. The cost is that any player who declines, or whose download fails for reasons that have nothing to do with you, is kicked off the server.

For a pack whose entire job is swapping music, that trade is usually bad. A player with a flaky connection losing access to your server over a disc track is a worse outcome than that player hearing Cat instead of your custom song. Leave it false unless the pack carries something genuinely load-bearing, and write a resource-pack-prompt that tells people what they are accepting and why.

Bedrock Dedicated Server works completely differently

There is no URL to point at on Bedrock. The server holds the pack files itself and pushes them to clients over the game connection, so the setup is filesystem work rather than a hosting problem.

1. Unzip your .mcpack into a folder inside the server's resource_packs/ directory, so that manifest.json sits at the top of that folder.
2. Open manifest.json and copy the uuid and version from its header block.
3. In your world folder, create or edit world_resource_packs.json and list the pack:

   [
     {
       "pack_id": "c50a9d81-4fea-488c-8d7e-a2856a10044c",
       "version": [1, 0, 0]
     }
   ]

4. Optionally set texturepack-required=true in server.properties, the rough equivalent of Java's require-resource-pack.

The UUID is the join between the two files, and it has to match exactly. MineVinyl generates a fresh UUID pair for each Bedrock pack — which is why re-generating a pack from scratch produces something Minecraft treats as a different pack, and why importing and editing an existing pack preserves them instead.

Note that Realms and most commercial Bedrock hosts expose their own upload UI for this rather than raw file access, and some Bedrock hosting does not permit custom packs at all — worth checking before you plan around it.

Common failure modes

• “Failed to download resource pack” — nine times in ten the URL is not a direct download. Run the curl -IL check above. Also confirm the host is reachable over plain HTTPS from a residential connection, not just from inside your datacentre.
• Players still hear the old audio — stale resource-pack-sha1. Re-hash the uploaded file and restart.
• Pack applies but discs play vanilla music — the pack loaded fine; the problem is inside it. Usually a pack_format that does not match the server's Minecraft version. See pack_format explained.
• Works in single-player, not on the server — the server pack takes over from locally installed packs while you are connected. If your local pack was doing the work, the server copy has to contain the same discs.
• Nothing happens at all — check the server actually restarted after you edited server.properties, and that the file was not rewritten over your edit by a running server.
• Some players fine, others not — almost always client-side cache. Have them delete the cached copy from their .minecraft/server-resource-packs/ folder and reconnect.

Still stuck? The troubleshooting guide covers pack problems that are not server-specific.