--- title: "How to Become an Admin on a 7 Days to Die Server" description: "Become an admin on your Winheberg 7 Days to Die server, find the player EOS ID, use the admin command from the panel console and understand permission levels from 0 to 1000." category: jeux subcategory: 7-days-to-die icon: tabler:user-shield date: 2026-09-08 author: Winheberg slug: "become-admin-7-days-to-die" order: 88 image: /statics/images/docs/en/gaming/7-days-to-die/become-admin-7-days-to-die.webp tags: [7 Days to Die, Administration, Permissions, Game panel] keywords: [7 days to die admin, serveradmin.xml, admin add command, eos id, permission level, 7 days to die server] link_fr: "/docs/7-days-to-die/devenir-admin-7-days-to-die" --- ## Context On a 7 Days to Die server, owning the server grants no in game privilege. Admin rights are declared in a dedicated file, `serveradmin.xml`, and until your account appears in it, the in game console will refuse most commands. Two details usually catch people out. First, the identifier used is not necessarily your SteamID, the game relies on platform identifiers including EOS. Second, the permission scale runs the opposite way to intuition, `0` is the highest level of rights and `1000` is the ordinary player. This guide covers the method the game itself recommends, going through console commands from the Winheberg game panel, along with the file structure for those who want to understand what happens behind the scenes. ## Requirements - An active [7 Days to Die server](https://winheberg.com/en/gaming/7-days-to-die) on the Winheberg game panel - The player to promote must have connected to the server at least once - Access to the server's **Console** tab on [panel.winheberg.com](https://panel.winheberg.com/) > [!NOTE] > The `serveradmin.xml` file itself states that it should be modified only through the matching console commands rather than by hand. That is the method used in this guide. ## 1. Find the player identifier The game identifies a player by a platform and identifier pair. For a PC player connected through Steam, the identifier used server side is most often their EOS ID. A player cannot read their own EOS ID from the game. They therefore need to connect to the server once, after which you can read the identifier server side. In the panel's **Console** tab, with the server running, run the following command. ```text listplayers ``` The output lists connected players. The identifier appears as `crossid=EOS_0002a2eacfff46808543ffdab9380672`, and it is the part **after** the `EOS_` prefix that acts as the identifier. Two related commands are useful. ::MdTable{caption="Commands for reading identifiers" variant="info" striped} | Command | Result | |---|---| | `listplayers` or `lp` | Lists connected players with identifiers, positions and status | | `listplayerids` or `lpi` | Lists players and their identifiers, shorter output | | `pplist` | Prints persistent player data, including offline players | :: > [!TIP] > The identifier is also written to the server log on every connection. If the player is no longer online, the panel console or the log file remain usable. ## 2. Add the admin from the console The `admin` command handles rights. Its syntax accepts a player name, an entity id or a platform identifier, followed by the permission level. ```text admin add ``` To grant full rights to a connected player, going through their name is simplest. ```text admin add Maxime 0 ``` If the name contains spaces, wrap it in quotes. ```text admin add "My Name With Spaces" 0 ``` Removal follows the same pattern. ```text admin remove Maxime ``` And the list of declared admins comes from the following command. ```text admin list ``` > [!NOTE] > Commands are typed without a leading slash in the panel console, unlike the in game chat. ## 3. Understand permission levels This is what trips up most people. The scale runs from `0` to `1000`, and a **lower** number means **more** rights. ::MdTable{caption="How the permission scale works" variant="info" striped footer="The game defines no named roles, only this numeric scale."} | Value | Meaning | |---|---| | `0` | Highest level, access to every command | | Intermediate values | Yours to define, a moderation tier for instance | | `1000` | Level given by default to any player not declared in the file | :: The principle is this. Each command carries a required level, and a player can run any command whose level is equal to or above their own. A player at `0` can therefore do everything, a player at `1000` can only run commands open to everyone. Commands not listed in the file default to level `0`, meaning they are reserved for full admins. ## 4. Check the result in serveradmin.xml After an addition, `serveradmin.xml` holds an entry in the `` section, in this form. ```xml ``` The `platform` attribute accepts `EOS`, `Steam`, `XBL` and `PSN`. The `name` attribute is purely cosmetic, it only reminds you who the entry belongs to. > [!WARNING] > Many tutorials still online show a `` syntax inside an `` section. That form belongs to an older game version and no longer works. The current form uses `platform` and `userid` inside a `` section. To locate the file, the most reliable route is the `UserDataFolder` line printed at the top of the server startup log, the file living in the `Saves` subfolder of that directory. You can also use the panel file manager search on the name `serveradmin.xml`. On Winheberg servers, that folder is `.local/share/7DaysToDie/Saves`, reachable from the **Files** tab with hidden folders shown. Folder .local/share/7DaysToDie/Saves in the Files tab of the Winheberg panel with the serveradmin.xml file circled in red ## Troubleshooting ### ❌ Commands are refused despite the entry - Check that the player disconnected and reconnected after being added - Confirm the level given is `0` and not `1000`, the scale is inverted - Check the identifier matches the right player by comparing it with the `lpi` output ### ❌ The identifier is not recognised - Drop the `EOS_` prefix, only the identifier that follows should be entered - Avoid copying the identifier from a screenshot, one wrong character is enough - Use the player name while they are connected instead, it is the safest route ### ❌ serveradmin.xml stays empty - The file is only filled in on the first use of the `admin` command - Check you are reading the file in the server save folder and not a copy elsewhere - Confirm the server was stopped before you read it, changes may only be written on shutdown ## Best practices - Grant level `0` sparingly, it opens commands that can permanently alter the world - Define an intermediate level for moderators rather than handing them full powers - Keep a separate note mapping names to identifiers, names change, identifiers do not - Use console commands rather than editing the file by hand, as the game itself recommends - Copy `serveradmin.xml` before any manual edit, a single XML syntax error can stop it loading - Combine admin rights with the whitelist if you open the server to strangers, see [How to Enable the Whitelist on a 7 Days to Die Server](https://winheberg.com/en/docs/enable-whitelist-7-days-to-die) ## Need help If rights do not apply despite a correct entry in the file, open a ticket with our support team from your [client area](https://billing.winheberg.com), **Technical** department, with the server in the **Related Product** field. Our team can check the file content and the connection logs with you. You are now in control of your server. 🎮