7 Days to Die admin commands, serveradmin.xml and modlets

Administering a 7 Days to Die server comes down to two files and one console. serveradmin.xml decides who is an admin, who is banned, and which commands each permission level may run. The console - reachable from the game with F1 as an admin, from telnet, or from your host's panel - runs the commands. Everything else, from horde night tuning to the loot table, is either a setting in serverconfig.xml or a modlet in the Mods folder.

This guide covers the permission system in detail, the remote paths and why one of them should never face the internet, the console commands that are actually useful, and how modlets work: where they go, how XPath patching applies them, what EAC blocks, and what happens to a world when you remove a mod that added blocks. For the settings file itself - world size, zombie counts, blood moon - see 7 Days to Die server settings.

Where admin lives: serveradmin.xml#

The file sits in the server's user data folder, beside the saves, and its name comes from the AdminFileName property in serverconfig.xml (default serveradmin.xml). The folder itself is UserDataFolder, which on a Linux server defaults to ~/.local/share/7DaysToDie/ and on Windows to %APPDATA%\7DaysToDie\. If you cannot find it, set UserDataFolder explicitly in serverconfig.xml so you always know where it is.

A file for version 1.0 and later looks like this:

<adminTools>    <admins>        <user platform="Steam" userid="76561198000000000" permission_level="0" name="you" />        <user platform="Steam" userid="76561198000000001" permission_level="100" name="a moderator" />    </admins>    <permissions>        <permission cmd="kick" permission_level="100" />        <permission cmd="ban" permission_level="100" />        <permission cmd="say" permission_level="100" />        <permission cmd="lp" permission_level="1000" />    </permissions>    <whitelist>        <user platform="Steam" userid="76561198000000002" name="a friend" />    </whitelist>    <blacklist>        <user platform="Steam" userid="76561198000000003" reason="griefing" />    </blacklist></adminTools>

platform is the account network - Steam for a Steam client, a different identifier for Epic, Xbox or PlayStation accounts on a crossplay server. userid is that platform's ID, a 17-digit number beginning 76561198 for Steam. name is a comment for you; it has no effect.

Use lp in the console to get the exact platform and ID for a connected player, rather than typing a Steam ID from a profile URL and hoping.

Permission levels, and the rule that trips people up#

Levels run from 0 to 1000. Lower is more powerful. A player with no entry in <admins> is 1000.

• 0 is the owner level: every command, no exceptions.
• 1 to 999 is an admin who can be restricted by the <permissions> list.
• 1000 is an ordinary player.

The rule for whether a command runs is worth reading twice: a player may run any command whose required level is greater than or equal to their own. So a command listed at permission_level="1000" can be run by everybody, and a command listed at permission_level="0" can be run only by a level 0 admin. A command not listed in <permissions> at all defaults to level 0, which is why a fresh server lets nobody but the owner do anything.

That gives you a simple staffing model. Put your moderators at level 100 in <admins>, then list exactly the commands they need at 100:

Changes to serveradmin.xml are picked up without a restart on current builds, but the console commands are still the reliable route, because they write and reload in one step.

Telnet, the control panel and the port you should not open#

7 Days to Die ships its own remote admin interface, configured in serverconfig.xml:

Telnet is plain text. The password crosses the network unencrypted, every command is readable by anything on the path, and the protocol has no concept of a session key. It was designed for a control panel talking to a server on the same machine, and that is the only place it belongs. The same is true of the built-in web control panel, which is plain HTTP.

So: leave telnet enabled with a password, and do not expose port 8081 to the internet. If you need remote administration, use your host's console, which reaches the server over the local network rather than across the world. The general argument is in RCON safely and the port-by-port version is in firewall rules that matter.

The game ports themselves:

Changing ServerPort moves the two UDP ports above it as well. Game server ports explained covers why a game needs more than one and what breaks when only some of them are reachable.

The console commands worth knowing#

There are well over a hundred. These are the ones you will use. Most have a short alias, given in brackets.

Moderation:

Information:

World and players:

Server:

Two of those deserve more than a table row.

shutdown is the only correct way to stop a 7 Days to Die server. The world is stored as region files, and a process killed mid-write leaves one damaged - which shows up later as a specific area that crashes anyone who walks into it, not as an error at startup. Use the panel's Stop button, which sends a clean signal, or run shutdown first. Restoring a single damaged region from a backup is far quicker than restoring the world, so keep backups you can browse rather than only whole-world archives.

setgamepref changes a preference on the running server and does not write it to serverconfig.xml. That makes it perfect for an experiment - drop BloodMoonEnemyCount mid-week and see what the CPU does - and a trap for anything you want to keep, because the next restart reverts it. Some preferences are read only at world generation and will not change anything at all, whatever the console says. Check with gg after you set one.

Modlets: where they go and how they load#

7 Days to Die has no workshop. Mods are folders you place in a Mods directory at the server root, next to Data/ and the server binary. Create it if it does not exist. Each modlet is one subfolder with a ModInfo.xml at its root:

Mods/  MyTweaks/    ModInfo.xml    Config/      blocks.xml      loot.xml  SomeUIMod/    ModInfo.xml    Config/    Resources/

ModInfo.xml in 1.0 and later is flat:

<?xml version="1.0" encoding="UTF-8" ?><xml>    <Name value="MyTweaks" />    <DisplayName value="My Tweaks" />    <Version value="1.0.0" />    <Description value="Small balance changes" />    <Author value="you" />    <Website value="" /></xml>

Older modlets wrap all of that in a <ModInfo> element inside <xml>. The wrapper form stopped being the current one at 1.0, so a modlet that has not been touched since Alpha 21 may not be recognised at all. A mod that simply does not appear in the startup log is usually this, not a bad install.

Modlets load in alphabetical order of their folder names, and later patches beat earlier ones when both touch the same value. That is the whole load-order mechanism: if you need one modlet to win, rename its folder so it sorts last. Prefixes like 00_ and zz_ are the community convention and they work because they are just filenames.

Writing and debugging an XPath patch#

A modlet does not replace a vanilla config file; it patches one. Put a file in Config/ with the same name as the vanilla file in Data/Config/, wrap the contents in <configs>, and describe the change:

<configs>    <set xpath="/blocks/block[@name='BLOCK_NAME']/property[@name='MaxDamage']/@value">1200</set>    <append xpath="/blocks">        <block name="myNewBlock">            <property name="Extends" value="BLOCK_TO_COPY" />        </block>    </append>    <remove xpath="/blocks/block[@name='BLOCK_NAME']/property[@name='DowngradeBlock']" /></configs>

The instructions available are set, setattribute, removeattribute, append, insertBefore, insertAfter, remove and csv. The xpath has to match the vanilla file exactly, so open Data/Config/blocks.xml on the server and copy the path out of it rather than guessing at element names.

The important debugging fact: a patch whose xpath matches nothing does not crash the server. It logs a warning and the game carries on with the original value. So a modlet that "does nothing" has almost always failed to apply, and the reason is in the server's output log, which the panel console shows at startup. Search it for the modlet's name; you will get either a line saying it loaded and applied, or a line saying a patch did not match.

This is also why version churn hurts. When a game update renames a property, every modlet that patched it silently stops working while appearing to be installed. After any update, read the startup log before you read the forums.

EAC, clients and what players have to install#

EACEnabled in serverconfig.xml controls Easy Anti-Cheat. The rule of thumb:

• A modlet that is only XML normally runs with EAC enabled.
• A modlet that ships a `.dll` does not. Set EACEnabled to false, and players who need the client half have to start the game without EAC from the launcher.

Turning EAC off is a real cost, not a formality. It is what stops the common flying and item-spawn cheats, and on a public server you will notice. If you can get what you want from XML alone, do.

There is no automatic mod delivery to clients. Nothing subscribes players to anything, and nothing is pushed on connection. What each player needs depends on what the modlet changes:

• Server only is possible for things the server alone evaluates: loot table weights, spawning rules, quest rewards.
• Both sides is required for anything the client draws or predicts: new items, new blocks, recipes, icons, models, sounds, UI.

Assume both sides unless the author says otherwise, and hand players a zip of the exact Mods folder you are running, not a list of links. A player who downloads a newer version of one mod than the server has will fail in confusing ways rather than being told.

On a crossplay server this settles itself: console players cannot install anything, so a modded server that needs client files is a PC-only server whatever the crossplay setting says.

Troubleshooting#

Nothing I type in the console works. You are not an admin, or you are an admin at a level above the command's requirement. Run admin list from the server console itself, which always has level 0.

A ban did nothing. You banned the player name on a server where they can reconnect under a different one. Ban the platform ID from lp instead.

Telnet refuses my password. TelnetPassword is empty, which allows local connections only, or the address is blocked after failed attempts - wait out TelnetFailedLoginsBlocktime.

The modlet is in the folder and does nothing. Three candidates, in order: the ModInfo.xml format is the old nested one; the folder structure is wrong, with the modlet nested one level too deep inside its download; or the xpath does not match. The startup log tells you which.

Settings I changed in the console reverted. setgamepref is session-only. Write it into serverconfig.xml too.

A specific area crashes players. A damaged region file, almost always from a server killed rather than shut down. Restore that region from a backup rather than the whole world.

Performance collapses on horde night and not before. That is the load test, and it is a sizing question rather than an admin one. le during the horde tells you how many entities are alive, and 7 Days to Die server settings covers which numbers to cut.

FAQ#

How do I make myself admin on a 7 Days to Die server?

From the server console, run admin add <your platform id> 0. Get the ID from lp while you are connected. Editing serveradmin.xml by hand works too, but the command writes it in the format your build expects.

What permission level should moderators have?

100 is the usual choice. It is well below the 1000 that ordinary players get and well above 0, so you can grant kick, ban and say at 100 in the <permissions> section while leaving item spawning and shutdown at 0.

Is it safe to open the telnet port?

No. Telnet sends the password and every command in clear text. Keep TelnetEnabled on with a password for local tools, keep port 8081 closed to the internet, and administer the server through your host's console instead.

Do my players need to install the mods?

Usually yes. There is no workshop and nothing is pushed to clients. Server-only modlets exist for loot and spawning rules, but anything that adds an item, block, recipe or icon has to be on both sides at the same version.

Can I run mods with EAC enabled?

XML-only modlets generally work with EAC on. Anything containing a compiled .dll needs EACEnabled set to false in serverconfig.xml, and affected players must launch without EAC as well.

Why did my modlet stop working after an update?

A game update renamed or moved whatever its xpath was pointing at, so the patch no longer matches and is skipped with a warning. Check the startup log, then check the mod's page for a build-specific release. What to do when a mod update breaks has the wider routine.