RE:NODE

Guides11 min read

Rust admin commands: bans, teleport, spectate

The Rust admin commands you will actually use - owner and moderator grants, kicks and bans, teleport, spectate, noclip, items - and how to make them stick.

0 readers

Rust admin rights come from two console commands run on the server: ownerid <SteamID64> for full owner access and moderatorid <SteamID64> for moderators, followed by server.writecfg so they survive a restart. The player reconnects, opens the F1 console, and from then on kick, ban, teleport, spectate, noclip, god and inventory.give work for them. The same commands work from the server console, RCON or a panel console without anyone in the game. This is the full working list, grouped by job, with the details that cause most admin support questions.

Owners, moderators and where rights live#

Rust has two built-in staff levels, stored as auth levels on the player's SteamID64.

LevelGranted byCan do
Owner (auth level 2)owneridEverything, including granting and removing staff
Moderator (auth level 1)moderatoridMost admin tools: kick, ban, teleport, noclip, spectate
Player (0)-Nothing administrative

Rights are saved in server/<identity>/cfg/users.cfg, but only when you run server.writecfg. Until then they exist in memory and disappear on the next restart.

code
ownerid 76561198012345678 "Alice" "Server owner"moderatorid 76561198087654321 "Bob" "Weekend moderator"server.writecfgremovemoderator 76561198087654321removeowner 76561198012345678server.writecfg

The name and reason are notes for you, not checked by the game; the SteamID64 is what counts. Find it with status or players while the person is online, or from their Steam profile. The grant applies when the player connects, so they must reconnect after you run it.

These built-in levels are separate from Oxide or Carbon permissions. An owner does not automatically get every plugin's admin permissions unless they are also in the framework's admin group; Oxide (uMod) plugins covers that side.

Finding a SteamID64

Almost every command on this page is safer with a SteamID64 than with a name, so it pays to know where to get one quickly. A SteamID64 is the 17-digit number starting 7656119. Three reliable sources:

  • `status` in the console while the player is online prints each connected player's ID beside their name. Copy it from there rather than retyping it.
  • The server log. Every connection is logged with the player's name and ID, so a player who left an hour ago can still be found by searching the log for their name.
  • Their Steam profile. If the profile uses a custom URL, the number is not visible in the address; a SteamID lookup site converts the custom URL into the 64-bit ID.

Keep a staff document with the ID of every staff member and every player you have had to act against. When an argument starts in Discord three weeks later, nobody remembers which "Alex" it was.

Where to type admin commands

  • Server console: the panel console, or the terminal the server runs in. No prefix, full access, works with nobody online.
  • RCON: the same commands from a remote tool. Rust RCON and WebRCON covers setup and security.
  • F1 console in game: for staff who are connected. Many commands act on the person typing them - noclip, god, teleport2me - so they only make sense here.

Chat commands with a / belong to plugins, not to Rust. If someone says "/tp doesn't work", they are talking about a teleport plugin's permissions, not the game.

find <word> in any console lists matching commands and convars with a one-line description. It is the authoritative reference for your build, and the first thing to try when a command from an old guide is "not found".

Player lookup, kicks and bans#

CommandWhat it does
statusConnected players with SteamID, name, ping and connection time
playersA compact list of players
kick <name or id> "reason"Disconnects a player; the reason is shown to them
kickall "reason"Disconnects everyone, for example before a restart
ban <name> "reason"Bans an online player by name
banid <SteamID64> "name" "reason"Bans by ID, online or not
unban <SteamID64>Removes a ban
banlistBanned IDs
banlistexBanned IDs with names and reasons
server.writecfgWrites bans to bans.cfg so they survive restarts

Ban by SteamID64 when you can. Names change, contain characters that break commands, and two players can share part of a name. banid also lets you ban someone who has already logged off, which is most of the time when the reports arrive.

Write a reason that will make sense to someone else in three months - "aimbot, clip in #reports 2026-10-03" rather than "cheater". Server rules, moderation and staff covers evidence, appeals and consistency, which matter more than the commands.

Server bans are local to your server. Game bans from Facepunch and Easy Anti-Cheat are separate and global, and you cannot issue or lift them. Shared ban lists across many community servers exist through third-party tools such as BattleMetrics.

Moving around and watching players#

CommandWhat it does
noclipFly through everything; toggle
god true / god falseTake no damage
debugcameraA free camera detached from your character
spectateSpectate a random player; again to cycle
spectate <name or id>Spectate a specific player
respawnLeave spectate mode
teleport <player>Move yourself to a player
teleport <player1> <player2>Move player1 to player2
teleport2me <player>Bring a player to you

spectate is the core tool for checking a cheating report. You see exactly what the player sees, from their perspective, without being in the world. Leave with respawn, which puts your own character back - check where it will be before you do it in the middle of someone's base.

debugcamera is the other investigation tool: a free-flying camera that is ideal for inspecting an unusually large base, checking a reported glitch spot or seeing whether a building is legal, without your character being present.

Most admins bind the common ones to keys in the F1 console. Binds are client-side and saved by your game client:

code
bind z noclipbind x debugcamerabind c "god true"

Investigating a report, step by step#

Most admin work is not banning; it is checking whether a report is true. A routine that staff follow the same way every time produces decisions that hold up when they are challenged.

  1. Get the report in writing. Who, when, where on the map, and what they saw. A clip if there is one. Reports made in global chat in the heat of a fight are a prompt to look, not evidence.
  2. Identify the player. Run status, find the name, copy the SteamID64. If several players have similar names, confirm with the reporter before you do anything.
  3. Watch before acting. spectate <SteamID64> and observe for long enough to see a pattern: snapping onto targets through cover, impossible movement, knowing where stashes are. One suspicious moment proves nothing; Rust's netcode produces strange-looking kills on its own.
  4. Check the base or location if relevant. For building exploits or glitched bases, fly in with debugcamera or noclip and look at the structure from outside and inside. ent who on a suspicious object tells you who it belongs to.
  5. Record what you saw. A note in the staff channel with the time, the ID, what you observed and any clips. If a ban follows, the reason in banid should point to this note.
  6. Act proportionately. A warning for a first minor rule break, a kick to end an ongoing problem, a ban for cheating or repeated abuse. Write the config afterwards.
  7. Tell the reporter. Not the details, but that it was looked at. Players who feel reports disappear stop reporting and start retaliating.

Two things to avoid. Do not ban on another player's word alone, however trusted they are; and do not announce bans with the player's name in global chat. The first creates false-positive bans that are hard to undo, the second turns moderation into theatre.

Items, entities and the world#

CommandWhat it does
inventory.give <shortname> <amount>Gives you an item
inventory.giveto <player> <shortname> <amount>Gives a player an item
spawn <prefab>Spawns an entity where you look, e.g. spawn minicopter.entity
ent killDestroys the entity you are looking at
ent whoShows information about the entity you look at, including ownership
env.time <hour>Sets the time of day, e.g. env.time 12
heli.callCalls the patrol helicopter

Item shortnames are the internal names: rifle.ak, ammo.rifle, wood, stones, metal.fragments, scrap. Display names do not work. Lists of shortnames are widely published; within the game, a plugin or the item's own ID is the fastest way to confirm one.

spawn uses entity prefab names, which are not the same as item shortnames - the minicopter you craft is not the entity you spawn. If a spawn command does nothing, the prefab name is probably wrong for your build, and the console output says so. env.time changes the in-game clock for everyone and is handy for testing builds at night or recording video, but leave the day cycle alone on a live server unless you announce it, because night is a tactical part of Rust.

Use world-changing commands sparingly and say so in a log channel. Every admin-spawned item on a vanilla server is an argument waiting to happen, and an ent kill on the wrong door will be called admin abuse within the hour. ent kill is the right tool for a glitched or exploit building the rules forbid; for player disputes it is the last resort.

Server control#

CommandWhat it does
say "message"Server-wide chat announcement
server.saveSaves the world now
restart <seconds> "reason"Countdown restart with in-game warnings
quitSaves and shuts down cleanly
serverinfoFrame rate, entities, memory, players as JSON
server.writecfgWrites staff and bans to disk
find <word>Lists matching commands and convars

Before anything risky - plugin changes, a manual wipe, a config experiment - run server.save and take a backup. quit saves on the way out; killing the process does not, and loses everything since the last save. Server performance and entity count explains what to look for in serverinfo, and server.cfg and convars covers settings you change from the same console.

What plugins add on top#

The built-in commands cover the essentials and stop there. On a modded server, a handful of admin plugins fill the gaps, and most communities with more than one moderator end up running some of them.

  • Vanish plugins make an admin invisible to players, so spectating from inside the world or checking a base does not announce itself. The built-in spectate already hides you; vanish is for when you need your own character present.
  • Admin radar plugins show players, sleepers, boxes and other entities through walls for staff only. They make finding a reported stash or a hidden base quick, and they are also exactly what a corrupt moderator would abuse, so log who uses them.
  • Chat moderation plugins add mutes with durations, word filters and chat logs, which Rust's base commands handle poorly.
  • Ban and report plugins add in-game /report commands, timed bans and a record of reasons, sometimes synced to Discord or a web panel.

Each of these registers permissions in Oxide or Carbon. Give them to a moderator group rather than to individuals, so adding and removing a moderator is one usergroup command plus moderatorid. Oxide (uMod) plugins has the group commands, and Rust RCON and WebRCON covers the external tools that often replace these plugins for larger teams.

A staff setup that holds up#

The commands are the easy part. The structure around them is what keeps a server from falling apart over a staff dispute.

  1. One or two owners. Everyone else is a moderator, and moderators cannot create staff.
  2. Moderator rights match the job. On a modded server, the framework's permissions decide which admin plugins a moderator can use. Give the minimum: a moderator who handles reports needs spectate and ban, not item spawning.
  3. Grants recorded in one place. A pinned list of every ownerid, moderatorid and permission grant, so you can rebuild staff after a mistake and remove someone completely when they leave.
  4. Logged actions. Admin plugins and RCON tools can log kicks, bans, spawns and teleports. A log that staff know exists prevents most abuse.
  5. Removal checklist. When someone leaves staff: removemoderator, remove them from framework groups, change the RCON password if they had it, remove panel access, server.writecfg.

Panel access is part of the same picture. Moderators who need the server console but not files or billing should have console-only panel access, not the account password. RE:NODE's panel supports exactly that: subusers with granular permissions (console only, files only, no billing), roles and teams, time-boxed access and a per-server activity log. Subusers and least privilege explains how to set it up.

Troubleshooting admin problems#

Staff lose admin after a restart. server.writecfg was not run after ownerid or moderatorid.

The command is "not found" in F1. The player is not admin yet - they must reconnect after the grant - or the command name has changed. Try find.

Owner commands work but plugin admin commands do not. Plugin permissions are separate. Add the player to the framework's admin group.

`ban` says no player found. The player is offline or the name matched nobody. Use banid with the SteamID64.

A banned player is back. The ban was never written to bans.cfg, or they are on a different Steam account. Write config after every ban; for alternate accounts, a third-party ban tool or anti-cheat plugin is needed.

`teleport` moves the wrong person. Partial name matches. Use SteamIDs, or check status for similar names first.

FAQ#

How do I make myself admin on a Rust server?

Run ownerid <your SteamID64> "name" "reason" in the server console, then server.writecfg, then reconnect. Your auth level is applied when you join.

What is the difference between ownerid and moderatorid?

Owners have every admin command and can grant or remove staff. Moderators get most moderation tools - kicks, bans, teleport, spectate - but cannot create other staff.

How do I ban someone who is offline?

Use banid <SteamID64> "name" "reason", then server.writecfg. You need their SteamID64, which you can find in previous status output, logs or their Steam profile.

How do I spectate a player in Rust?

As an admin, type spectate <name or SteamID> in the F1 console. Type spectate alone to cycle through players, and respawn to return to your own character.

Why do my admin commands disappear after a restart?

Because grants and bans live in memory until server.writecfg writes them to users.cfg and bans.cfg. Run it after every staff or ban change.


Comments

Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.

0/2000