--- title: "How to Enable the Whitelist on a 7 Days to Die Server" description: "Restrict access to your Winheberg 7 Days to Die server with the whitelist, automatic activation from the first entry, console commands and the whitelist section of serveradmin.xml." category: jeux subcategory: 7-days-to-die icon: tabler:lock-check date: 2026-09-08 author: Winheberg slug: "enable-whitelist-7-days-to-die" order: 89 image: /statics/images/docs/en/gaming/7-days-to-die/enable-whitelist-7-days-to-die.webp tags: [7 Days to Die, Whitelist, Security, Game panel] keywords: [7 days to die whitelist, serveradmin.xml, whitelist add, private 7 days to die server, restrict server access, eos id] link_fr: "/docs/7-days-to-die/activer-whitelist-7-days-to-die" --- ## Context A server password gets shared, copied and always ends up circulating. When you want to keep a 7 Days to Die server to a specific group, friends, a closed community or a test server, the whitelist is a stronger control, since it relies on each player's identifier rather than a shared secret. How it works holds one surprise. There is no option to tick to enable it, and no matching property in `serverconfig.xml`. The whitelist turns itself on as soon as it holds at least one entry, and turns itself off as soon as it is emptied. This guide covers enabling it from the Winheberg game panel, managing entries, and the classic mistakes that lock everyone out. ## Requirements - An active [7 Days to Die server](https://winheberg.com/en/gaming/7-days-to-die) on the Winheberg game panel - The players to authorise must have connected at least once, so you can read their identifier - Access to the server's **Console** tab on [panel.winheberg.com](https://panel.winheberg.com/) > [!CAUTION] > From the very first entry added, nobody else can join the server. Add your regular players before considering the switch done, or you will find yourself alone online. ## 1. Understand how it activates The `serveradmin.xml` file holds a `` section, empty by default. Its internal comment is unambiguous, as soon as an item appears in it, whitelist only mode is enabled, and nobody can join outside of the listed players and the admins. ::MdTable{caption="Whitelist state by content" variant="info" striped} | Section content | Server behaviour | |---|---| | No entry | Server open to everyone, whitelist inactive | | At least one entry | Access reserved for listed players and admins | :: > [!IMPORTANT] > Admins declared in the `` section keep access even when they are not in the whitelist. That is your safety net if you lock yourself out, provided you declared your account as an admin beforehand. ## 2. Read the player identifiers As with admin rights, the game identifies a player by a platform and identifier pair, the EOS ID for most PC players. Ask each player to connect once to the server, then run the following command from the panel's **Console** tab. ```text listplayerids ``` The identifier appears in the output as `crossid=EOS_0002a2eacfff46808543ffdab9380672`. Only the part after the `EOS_` prefix is to be kept. For the detailed procedure, see our guide [How to Become an Admin on a 7 Days to Die Server](https://winheberg.com/en/docs/become-admin-7-days-to-die) ## 3. Add players to the whitelist Management goes through console commands, without a leading slash. ```text whitelist add ``` While a player is connected, their name is enough. ```text whitelist add Maxime ``` Removal and listing follow the same pattern. ::MdTable{caption="Whitelist management commands" variant="info" striped} | Command | Effect | |---|---| | `whitelist add` | Adds a player to the whitelist | | `whitelist remove` | Removes a player from the whitelist | | `whitelist list` | Prints the list of allowed players | :: > [!TIP] > Start by adding yourself, then check with `whitelist list` before adding the rest of the group. You confirm the command behaves as expected before the restriction applies to everyone. ## 4. Check the file content The matching section of `serveradmin.xml` looks like this once filled in. ```xml ``` The `name` attribute is optional and purely cosmetic. `` entries allow a whole Steam group, identified by its group `steamID`. To locate the file, read the `UserDataFolder` line at the top of the server startup log, the file living in the `Saves` subfolder of that directory. 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 ## 5. Disable the whitelist There is nothing to untick. Empty the section of all its entries and the server becomes open to everyone again at the next restart. ```text whitelist remove ``` Repeat for each entry, then confirm with `whitelist list` that the list is empty. ## Troubleshooting ### ❌ Nobody can join the server any more, including me - Check that your account is declared as an admin in the `` section, admins bypass the whitelist - If you have no admin access, empty the `` section from the panel's **Files** tab with the server stopped - Restart the server after the change, the file is read at startup ### ❌ An authorised player is still refused - Compare their identifier with the `lpi` output, one wrong character breaks the match - Check that the `EOS_` prefix was removed from the stored identifier - Confirm the entry sits in the `` section and not elsewhere in the file ### ❌ The whitelist does not seem to apply - Check the section really holds an active entry and not only the commented out examples shipped with the file - Lines between XML comment markers are not taken into account - Restart the server to force the file to be read again ## Best practices - Declare yourself as an admin before enabling the whitelist, it is the only way to keep access after a mistake - Maintain a mapping between names and identifiers, names change over time - Add players in small batches and check with `whitelist list` after each round - Warn your community before enabling it, a player refused without explanation assumes a server problem - Keep a copy of `serveradmin.xml` before any manual edit, a single XML syntax error can stop it loading ## Need help If a correctly listed player is still refused, or if you lost access to your own server, 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 work on the file with you. Your server now welcomes only the players you chose. 🔒