Resolved as of 1.4.3 beta 2. Dedicated servers are rendered inoperable until restarted when a player with an unknown species attempts to join. When a player with an unknown species (i.e. not installed server-side) joins the server, MapException errors with the species' name are thrown until the client disconnects. After this event, all subsequent connections will cause the same error, regardless of player species, until the server is manually restarted. Since this occurs very early in the connection process, no built-in acess controls can be used to mitigate the issue. TL;DR: Anyone can crash any server, even if they're banned, by simply installing one of the hundreds of species mods and joining the server. A starbound_server.log depicting the issue is attached. This setup was used: A Manjaro Linux installation. (amd64, 16.06.1) Also observed on Ubuntu Xenial (amd64, 16.04.1 LTS) A vanilla starbound_server running on localhost. (Any version from 1.0.0 and up) "allowAssetsMismatch" set to true in starbound_server.config. A client with the Familiars and Xbawks mods installed. A vanilla Glitch character. (Name: "devBot", UUID : "ff00ff00ff00ff00ff00ff00ff00ff00") A modded Familiar character (Name: "Bogon", UUID : "deadbeefdeadbeefdeadbeefdeadbeef") The character must have completed the initial quest. Otherwise, they will simply receive a client shipworld error. These steps were used: Start the vanilla server. Join with the vanilla character. ("devBot") Disconnect from the server. Attempt to join with the modded character. ("Bogon") Send a SIGKILL to the client. - Could not disconnect otherwise. Attempt to join with the vanilla character again. ("devBot") Send a SIGKILL to the client. - Could not disconnect otherwise. Send a SIGINT to the server. Setting "allowAssetsMismatch" to false in starbound_server.config does mitigate this issue. However, this may not be an option for some servers - mine included. Edit: When a server experiences this error, it will continue to complete TCP handshakes and respond to RCON commands. This means very little for clients but becomes fairly significant for monitoring and recovery scripts. Unless the monitoring/recovery script watches for this error, it will likely return a false reading and assume the server is functioning correctly. Edit: I've written a patch for the StarryPy3k server wrapper allowing species whitelisting and it has since gone upstream. StarryPy3k is available here.