docker-minecraft-bedrock-server
                                
                                 docker-minecraft-bedrock-server copied to clipboard
                                
                                    docker-minecraft-bedrock-server copied to clipboard
                            
                            
                            
                        Network Port Occupied
Just pulled the docker image however when I launch the container I am having an issue with the "network port occupied".
minecraft | time="2019-09-05T09:27:15-04:00" level=debug msg="Using /data to match uid and gid" minecraft | time="2019-09-05T09:27:15-04:00" level=debug msg="Resolved UID=1000 from match path" minecraft | time="2019-09-05T09:27:15-04:00" level=debug msg="Resolved GID=1001 from match path" minecraft | time="2019-09-05T09:27:15-04:00" level=debug msg="failed to read stdin" error=EOF minecraft | Starting Bedrock server... minecraft | NO LOG FILE! - setting up server logging... minecraft | [2019-09-05 09:27:16 INFO] Starting Server minecraft | [2019-09-05 09:27:16 INFO] Version 1.12.1.1 minecraft | [2019-09-05 09:27:16 INFO] Session ID 38380653-3312-4b55-b975-08139ed45610 minecraft | [2019-09-05 09:27:16 INFO] Level Name: Bedrock level minecraft | [2019-09-05 09:27:16 INFO] Game mode: 1 Creative minecraft | [2019-09-05 09:27:16 INFO] Difficulty: 1 EASY minecraft | [2019-09-05 09:27:18 INFO] IPv4 supported, port: 0 minecraft | [2019-09-05 09:27:18 INFO] IPv6 supported, port: 0 minecraft | [2019-09-05 09:27:18 ERROR] Network port occupied, can't start server. minecraft | Quit correctly
Have you manually changed your server.properties? It looks like server-port and server-portv6  have been set to 0 due to the logs
minecraft | [2019-09-05 09:27:18 INFO] IPv4 supported, port: 0
minecraft | [2019-09-05 09:27:18 INFO] IPv6 supported, port: 0
This output was on a clean pull / build.
Thinking that something was up with the set-properties I added a ipv4/ipv6 port option to the property-definitions.json file to allow setting port via an ENV variable - hoping that something was getting nuked during entry. This did not help either, while I can see my env set ports being set in the properties its still showing as 0 in the log.
I did see something that seems similar:
https://bugs.mojang.com/browse/BDS-1264
I am struggling with testing disabling v6 within the docker image though...
This seems to be less your issue and more mine.
There are plenty of people having issues with BDS when their system has ipv6 disbaled (which I do).
https://bugs.mojang.com/browse/BDS-1264
Ah, thanks for the research into the root issue. I guess I have gotten lucky on the systems I have been deploying to.
I'm not sure when it stopped working for me, but just wanted to note that I am now getting the same error running Docker for Desktop with this version

...also noting that I tried adding --sysctl net.ipv6.conf.all.disable_ipv6=1 to docker run, but didn't make a difference and seems to match this report:
https://github.com/moby/moby/issues/20569#issuecomment-437071341
For whomever it may concern, I ran into this problem because I kept restarting the server on the same folder I was mounting it on, each time you restart the server that is binded to a file path you should also delete all the non-player data files (like stuff that has nothing to do with texture packs, maps etc..) that way it starts the installed BDS from scratch instead of using the pre-existing "corrupt" data that makes this error trigger, at least for me that's what I got, I do not know why it works that way but it just does and I'm not complaining. :)
either way good luck guys, keep the community updated.
EDIT:
May actually be that it does a shitty when it is binded to a directory using the -v flag because it then tries to use that directories user group and I guess because of that it just turns south for it, stick to accessing the container files from var/lib/docker/volumes instead of binding to a path directly even though it's a bit inconvenient when doing backups and what not it is safer to try not to trigger this issue.
This issue appears to be fixed with latest Edge release on Mac OS.