Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Godlike.Host offers hosted Minecraft Bedrock servers with its own game panel, SFTP access and free DDoS protection, if you would rather not host it yourself.
The Bedrock server error Port [19132] may be in use by another process means the server could not bind its local UDP listening socket. Check both UDP ports 19132 and 19133, then check Docker’s network namespace and published mappings—not just the host’s process list. Stop the duplicate or conflicting service cleanly, or move the server to an unused UDP port and update every related setting.
This is a startup failure, not a firewall or client-connection problem. Until the Bedrock process binds successfully, router forwarding and remote troubleshooting cannot make the server reachable.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchPC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11| # | Preview | Product | Price | |
|---|---|---|---|---|
| 1 |
|
Minecraft | Java & Bedrock Deluxe Collection | Windows Digital Code | $39.99 | Buy on Amazon |
| 2 |
|
Minecraft - Bedrock Edition PS4 | $42.98 | Buy on Amazon |
| 3 |
|
Minecraft - Nintendo Switch | $29.82 | Buy on Amazon |
| 4 |
|
Minecraft | $6.99 | Buy on Amazon |
| 5 |
|
Minecraft: Switch Edition | $32.65 | Buy on Amazon |
What the error actually means
Bedrock opens one or more UDP sockets during startup. If another process, container, or socket configuration already owns a required address and port, the bind call fails and the server exits. A documented Docker incident shows the sequence clearly: after loading the world database, the log reports:
[2023-05-29 09:06:11:367 ERROR] Port [19132] may be in use by another process. Free up port and re-run program
[2023-05-29 09:06:11:367 ERROR] Port [19133] may be in use by another process. Free up port and re-run program
Exiting programThe incident used Minecraft Bedrock 1.19.83.01 in an itzg/docker-minecraft-bedrock-server issue opened on May 29, 2023. That report demonstrates the failure, but it does not establish one universal cause for every machine. A fresh virtual machine can still have a duplicate container, an automatic service, a second shell-launched copy, or a host-to-container mapping conflict.
#1 Best Overall
- DELUXE COLLECTION — Includes Minecraft: Java & Bedrock Edition, three Bedrock add-ons, three exclusive Character Creator items, and 700 Minecoins.
- CREATE YOUR WORLD — Build whatever you imagine in an infinite world that’s unique in every playthrough.
- EXPLORE AND CRAFT — Discover biomes, resources, and mobs, then craft your way through a sandbox world filled with surprises.
- SURVIVE THE ADVENTURE — Face mysterious foes, travel across exciting landscapes, and venture into perilous dimensions.
- PLAY TOGETHER — Play cross-platform with friends in Bedrock Edition on console, mobile, and PC, or join community servers in Java Edition on PC, Mac, and Linux. Online console multiplayer requires a platform-specific subscription (sold separately).
Port 19132 is the usual IPv4 Bedrock port, while 19133 is commonly used for the IPv6 listener. Treat both as required until your configuration proves otherwise. Bedrock can refuse to start when either listener is unavailable.
First response: preserve evidence and avoid a blind reboot
Before stopping anything, save the complete startup log and the output of the port-ownership commands below. Those two records show whether the failure is on the host, inside a container, or in the Bedrock configuration. A reboot may make a stale process disappear, but it also removes the evidence and can allow an automated service to recreate the same conflict.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →- Copy the full log from the first startup line through
Exiting program. - Record whether the server is running directly on Linux, in Docker, or through Compose or another orchestrator.
- Note the exact values of
server-portandserver-portv6inserver.properties. - Keep the container ID, container name, and published-port output if Docker is involved.
Step 1: stop duplicate Bedrock instances
The most common fix is removing a second copy that is already publishing the ports. A container can remain after an update, a failed deployment, or a Compose project was started from a different directory.
List running Docker containers
docker ps --format 'table {{.ID}}t{{.Names}}t{{.Ports}}'Look for more than one Bedrock container and for any container publishing UDP 19132 or 19133. The port column may show entries such as 0.0.0.0:19132->19132/udp. Stop only the stale or unintended container, using its name or ID:
docker stop <container-name-or-id>Do not kill an unrelated service merely because it uses a familiar number. Confirm the image, name, project, and owner first. If a service manager, scheduled job, or orchestration system launches the container again, disable or correct that launcher before restarting the intended instance.
Check non-Docker launchers
Also inspect system services, terminal multiplexer sessions, startup scripts, and deployment jobs. A Bedrock process started manually in one shell can coexist with one started by a service manager. Stop the extra copy through the mechanism that owns it so it does not immediately return.
Rank #2
- Play and share with friends on console, mobile and Windows 10
- discover community creations in the new in-game store
- access new mini games and game modes through servers
Step 2: identify whoever owns UDP 19132 or 19133
On Linux, run both commands as root or with sudo:
sudo ss -ulpn | grep -E '19132|19133'
sudo lsof -nP -iUDP:19132 -iUDP:19133The output can include a process name, PID, local address, and (for Docker) a proxy or forwarding process. Record the PID or container relationship before stopping anything. A wildcard address such as 0.0.0.0:19132 means the socket is listening on all IPv4 interfaces; an IPv6 wildcard such as [::]:19133 can cover every IPv6 interface.
If ss shows no process
An empty host result does not prove that the port is free from Bedrock’s point of view. Check these boundaries:
- Container namespace: a process can listen inside a container while the host view shows only Docker’s publication or nothing after a failed, short-lived start.
- Timing: a duplicate process may exit between the failing startup and your command. Re-run the checks while the intended server is stopped and again immediately before starting it.
- Mapping conflict: Docker may reject or retain a host publication even when no ordinary application process appears in a quick scan.
- Address family: inspect both IPv4 and IPv6 output. A check that filters only one address family can miss the listener Bedrock is trying to open.
- Permissions and filters: an unprivileged command may omit process details, and a narrow grep pattern can hide an alternate representation of the address.
When the host remains empty, inspect the container list and Docker metadata next rather than repeatedly killing random PIDs.
Step 3: inspect the container and Compose layers
Docker adds another namespace and another owner for the same numbers. Verify the host publication, the internal Bedrock listener, and the project that created each container.
Look for duplicate published ports
In Compose files and deployment templates, search the ports section for both UDP mappings. A typical intentional mapping has the same host and container ports:
ports:
- "19132:19132/udp"
- "19133:19133/udp"Two Compose projects cannot both claim the same host UDP port. An old project started from another directory may be the hidden owner. Bring down the obsolete project, remove the duplicate mapping, or assign a different host port to the second server. Recreate the intended container after correcting the file rather than relying on an in-place restart that preserves stale networking.
Rank #3
- Minecraft is a game about placing blocks and going on adventures
- Explore randomly generated worlds and build amazing things from the simplest of homes to the grandest of castles
- Play in creative mode with unlimited resources or mine deep into the world in survival mode, crafting weapons and armor to fend off the dangerous mobs
- Play on the go in handheld or tabletop modes
- Includes Super Mario Mash-Up, Natural Texture Pack, Biome Settlers Skin Pack, Battle & Beasts Skin Pack, Campfire Tales Skin Pack; Compatible with Nintendo Switch only
Check host networking
A service using network_mode: host does not use isolated container ports; it binds directly to the host network. Treat its Bedrock settings as host settings and check it alongside native processes. Do not combine assumptions from bridge-mode publishing with host-mode behavior.
Inspect stopped and recently replaced containers
docker ps lists running containers only. Use your normal Docker inventory or deployment dashboard to find stopped, replacement, and old project containers. A stopped container cannot keep a socket open, but its Compose project or automatic restart policy may immediately launch another copy. Correct the source configuration and then recreate the desired container.
Step 4: verify Bedrock’s own port settings
Open the server’s server.properties file and check the listener values, especially:
server-portfor the IPv4/primary Bedrock listener.server-portv6when the file includes an IPv6 listener.
Confirm that these values match the ports you intend to publish. Changing only Docker’s host-side number does not automatically change the port Bedrock binds inside the container. Conversely, changing server-port without changing Docker, the firewall, and the router can leave the process running but unreachable.
Keep address-family choices deliberate
Decide whether you need IPv4, IPv6, or both. If both listeners are enabled, make sure 19132 and 19133 are each available in the relevant network namespace. Do not assume that a successful IPv4 check proves the IPv6 listener is free, or that changing one property disables the other.
Save the file, stop the server cleanly, and start it again. Verify the startup log before testing a remote client. A successful startup should proceed past the bind stage instead of ending with the port error.
Rank #4
- Skins! We have biome settlers, city folk, town folk, and more!
- The Nether and all its inhabitants. Fight Ghasts and make friends with Pigmen
- Cross platform play for up to five players between Pocket Edition and Windows 10
- Revamped touch controls, controller support, and a controller mapping screen
- Enhanced Weather effects! Accumulating snow and more
Step 5: recreate the intended service cleanly
- Stop the duplicate container or process identified in Steps 1–3.
- Correct the Compose mapping, restart policy, service definition, or shell script that launched it.
- Confirm that no process owns UDP 19132 or 19133, using both
ssandlsof. - Start one intended Bedrock instance.
- Immediately review the complete log and confirm that the process remains running after world initialization.
- Run the ownership checks again to verify that the expected process now owns the listeners.
If the same error returns, compare the newly captured log with the first one. A changing PID or container name points to an automatic launcher; an unchanged mapping points to the Compose or host configuration; a failure only on one address family points to the corresponding Bedrock property or socket.
When changing the port is the right fix
Move Bedrock only when another legitimate application requires the preferred port or you intentionally need separate servers. Microsoft networking guidance describes two valid remedies for an unavailable dedicated application port: locate the application using it, or choose a different dedicated port.
Changing ports creates a coordinated migration. Every layer must agree on the new UDP number:
| Layer | What to change | Why it matters |
|---|---|---|
| Bedrock | server-port and, when applicable, server-portv6 |
Determines the socket Bedrock attempts to bind. |
| Docker or Compose | Host-to-container UDP mappings, for example new:new/udp |
Publishes the listener outside the container. |
| Host firewall | Allow the chosen UDP port | Permits packets to reach the server process. |
| Router or NAT | Forward the chosen UDP port to the server’s private address | Delivers Internet traffic to the correct machine. |
| Clients | Enter the new address and port | Clients using the old number will continue targeting the old socket. |
Choose a port that is unused on the host and not reserved by another service. After editing, restart Bedrock, confirm ownership locally, and test from a client that uses the new port. A port change is not complete until the forwarding, firewall, and client settings are changed together.
Keep the default or move: a practical decision
| Decision factor | Keep 19132/19133 | Move to another UDP port |
|---|---|---|
| Existing owner | Works when no legitimate service needs either default listener. | Appropriate when another required application owns a default port. |
| Configuration work | Usually limited to removing the duplicate and recreating the intended service. | Requires coordinated Bedrock, Docker or Compose, firewall, router, and client edits. |
| Existing clients | Can continue using their current port. | Every client and saved server entry must be updated. |
| Multiple servers | Only one host service can claim each published UDP port. | Each server can receive its own unused UDP port, with matching forwarding. |
Keeping the defaults is usually the lower-risk choice when they are genuinely free. Moving is cleaner than disrupting a required application, but only if you can update all dependent settings and users.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Do not confuse a bind failure with a reachability failure
Use the server’s behavior to choose the right branch:
Best Value
- Explore randomly-generated worlds and build amazing things from the simplest of homes to the grandest of castles
- Play in Creative Mode with unlimited resources or mine deep into the world in survival mode, crafting weapons and armour to fend off the dangerous mobs
- It exits with “Port may be in use”: stay local. Find the owner, inspect container namespaces and mappings, and verify
server.properties. - It stays running, but clients cannot join: investigate the host firewall, NAT or router forwarding, public address, client port, and network path.
- It works locally but not from the Internet: the bind is probably successful; focus on forwarding, firewall policy, the server’s private address, and whether the client is using the correct public endpoint.
- Only IPv6 clients fail: inspect
server-portv6, IPv6 firewall rules, and IPv6 forwarding separately from IPv4.
Do not open router ports or change public DNS as the first response to a process that cannot bind locally. Remote forwarding cannot repair a failed local socket.
Fresh VM checks
A new Ubuntu 22.04 VM does not guarantee a clean Bedrock network state. The documented Docker reproduction published UDP 19132:19132 and still reached the bind error. On a fresh machine, check the installation and deployment layers in this order:
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →- List running containers and identify any image or project started by cloud-init, a startup script, or an earlier test.
- Inspect Compose files for two projects publishing the same UDP numbers.
- Check whether a host-networked container or native service is already binding the listener.
- Confirm that the mounted
server.propertiesis the file actually used by the running container. - Recreate one intended container and capture its complete startup log.
This sequence distinguishes a genuinely occupied socket from a mismatch between the file you edited and the configuration the container loaded.
Escalation when the port still appears free
If the server continues to report the error after the host, container, and configuration checks, preserve a reproducible record instead of repeatedly changing ports. Include:
- The full startup log, including the world-database lines and both port errors.
- Output from
sudo ss -ulpn | grep -E '19132|19133'andsudo lsof -nP -iUDP:19132 -iUDP:19133. - The formatted
docker psoutput with container IDs, names, and published ports. - The relevant
server.propertiesvalues, with secrets removed. - The Docker or Compose port and network settings.
- Whether the failure occurs with the container stopped, with one container started, and after a clean recreation.
The dated issue report does not establish a single universal root cause, so this context is more useful to maintainers than a statement that the VM was “fresh” or that ss was empty. If you cannot administer Docker, UDP binding, or router rules reliably, managed Bedrock hosting is an escalation option; choose a service that documents port changes, backups, logs, and network access before moving an existing world.
Quick verification checklist
- Both UDP 19132 and UDP 19133 have been checked.
- No duplicate Bedrock process, shell session, service, or container is launching.
- Docker and Compose publish each host port only once.
network_mode: hostis accounted for if present.server-portandserver-portv6match the intended listeners.- The intended process starts and remains running after world initialization.
- If the port changed, Bedrock, Docker, firewall, router, and clients all use the same new UDP number.
- Only after a successful bind do you troubleshoot NAT, firewall, or remote reachability.
Frequently Asked Questions
Why can a fresh Ubuntu VM report that Bedrock ports are already in use?
A fresh operating-system installation does not rule out a duplicate container, an automatic startup job, a host-networked service, or a second deployment created during setup. Check Docker inventory, service launchers, and both UDP listeners before assuming the operating system is at fault.
Recommended Free Tools
Should I kill the PID shown by ss?
Only after confirming that the PID belongs to the stale Bedrock instance or an unintended service. Record its process and container ownership first; stopping an unrelated application can create a new outage.
Will changing only the Docker host port solve the error?
Not necessarily. Bedrock must bind the internal listener defined by server-port or server-portv6. A port change works only when the Bedrock settings, Docker mapping, firewall, router forwarding, and client address all agree.
What information should I send when requesting help?
Send the complete startup log, both port-owner command outputs, Docker container and published-port output, the relevant Bedrock port properties, and the Compose or network settings. Include whether the failure persists after stopping all duplicates and recreating one intended instance.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
