The environment trap
You are troubleshooting a service that refuses to start. The logs point to a permission error on a configuration file. You run su to become root, enter the password, and the prompt changes to #. You edit the file, fix the permissions, and exit. Back in your normal shell, you run systemctl status and get command not found. You check your PATH and realize it still points to your user directories, not the system binaries. The shell looks like root, but the environment is a hybrid mess. This happens because su without arguments preserves your current environment. You have root privileges, but your shell still thinks it is your user.
This scenario breaks scripts, confuses editors, and causes subtle bugs that are hard to trace. Fedora provides tools to switch users and escalate privileges, but the difference between a clean switch and a broken one comes down to environment variables. Understanding how the shell loads its profile is the key to avoiding these issues.
How su and sudo differ
su stands for substitute user. It is the original Unix tool for changing identity. It asks for the target user's password and switches the process to that user. sudo stands for superuser do. It was designed to allow specific users to run specific commands as root without sharing the root password. sudo asks for your own password and checks the sudoers configuration to see if you are allowed to run the command.
Fedora follows the modern convention: sudo is the standard for privilege escalation. The wheel group controls who can use sudo. Your user is added to wheel during installation. su is still available for switching to other users or for recovery scenarios, but sudo provides better auditing and finer-grained control.
The shell environment is where most confusion happens. A login shell reads /etc/profile, ~/.bash_profile, and ~/.bashrc. It sets variables like HOME, PATH, USER, and SHELL to match the user. A non-login shell reads only ~/.bashrc. It inherits variables from the parent process. su without a dash starts a non-login shell. It keeps your PATH and HOME. su - forces a login shell. It resets the environment to match the target user. sudo -i does the same for root. It simulates a full login.
Check the environment before you run complex tasks. A wrong HOME directory breaks half the tools you rely on.
Switching to root safely
For a single administrative command, use sudo directly. This limits the scope of elevated access to just that command. It is safer and leaves a clear audit trail in /var/log/secure.
sudo dnf upgrade --refresh # --refresh forces dnf to check for newer metadata, ensuring you get the latest packages
sudo systemctl restart httpd # Restart the web server; sudo elevates this specific command only
When you need a persistent root shell for a series of configuration changes or debugging steps, use sudo -i. This starts a login shell as root. It loads /root/.bashrc, sets HOME to /root, and gives you a clean environment.
sudo -i # Start a login shell as root; this loads /root/.bashrc and sets HOME to /root
whoami # Verify you are now root
echo $HOME # Should print /root, confirming the environment switched correctly
exit # Return to your original user session
sudo -i is preferred over su - on Fedora because it respects the sudoers configuration and logs the action with your username. su - requires the root password, which is often disabled or unknown on default Fedora installations.
If you need to run a command as root but keep your current environment, use sudo -E. Use this sparingly. Preserving the environment can cause conflicts if your user variables clash with root expectations.
sudo -E my-script.sh # Run the script as root but keep your current environment variables
Verify the environment after switching. Run echo $HOME and echo $PATH. If HOME is not /root, you are not in a clean root shell.
Switching to another user
To switch to a different standard user, use su - username. The dash is critical. It tells su to simulate a full login by reading the target user's profile scripts. Without the dash, su username starts a non-login shell, which often results in missing environment variables like PATH or HOME, causing commands to fail unexpectedly.
su - alice # Switch to alice with a full login environment; the dash loads her profile scripts
echo $HOME # Should print /home/alice, confirming the environment switched correctly
exit # Log out of alice's session
If you need to run a single command as another user without switching shells, use sudo -u. This is useful for testing permissions or running a service as a specific user.
sudo -u www-data whoami # Run a command as www-data without switching shells
sudo -u alice -i # Start a login shell as alice using sudo; useful if su is restricted
sudo -u requires your user to be in the wheel group. It does not require the target user's password. It asks for your password and checks sudoers. This is safer than su because it does not expose the target user's password and allows administrators to restrict which users can be impersonated.
Check the target user's shell before switching. If the user has a broken .bashrc, su - might fail or produce errors. Run su - username and look for complaints about syntax errors in the profile scripts.
Common pitfalls and errors
The most common error is using su without the dash. This creates a shell with root privileges but your user's environment. Commands like ls might work, but scripts that rely on ~ or $HOME will operate on the wrong directory. Editors may save files with the wrong ownership. Always use su - or sudo -i for interactive work.
If you see user is not in the sudoers file. This incident will be reported., your user is not in the wheel group. Add the user to the group with usermod.
sudo usermod -aG wheel username # -aG appends the user to the wheel group without removing other groups
groups username # Verify the user is now in the wheel group
The -aG flag is essential. Using -G without -a replaces all groups, which can lock you out of other resources. Always append.
SELinux denials can cause permission errors even when file ownership looks correct. If you copy a file as root to a user's home directory, the SELinux context might be admin_home_t or root_home_t. The user cannot read the file. Use restorecon to fix the context.
sudo restorecon -Rv /home/alice/data # Recursively restore default SELinux contexts and verbosely report changes
ls -Z /home/alice/data # Verify the context matches user_home_t
restorecon uses the policy database to determine the correct context. It is safer than chcon, which sets a manual context that can drift over time. Fedora enforces strict SELinux policies by default. Trust restorecon for context repairs.
If you edit /etc/sudoers directly and make a syntax error, you can lock yourself out of sudo. Always use visudo. It checks syntax before saving.
sudo visudo # Edit the sudoers file safely; visudo checks syntax before saving to prevent lockouts
visudo opens the file in your editor, runs a syntax check on save, and warns you if the file is invalid. It prevents the common mistake of breaking sudo with a typo.
Check /var/log/secure or journalctl -t sudo to audit privilege escalation. journalctl -t sudo shows every sudo command, the user who ran it, and the outcome. This is invaluable for troubleshooting and security reviews.
journalctl -t sudo -xe # Show sudo log entries with explanatory text and jump to the end
The -x flag adds explanatory text from the man pages, and -e jumps to the end of the journal. Most sysadmins type journalctl -xeu <unit> muscle-memory style. Apply the same pattern here.
Choosing the right tool
Use sudo command when you need to run a single administrative task and return to your user immediately. Use sudo -i when you need a persistent root shell for a series of configuration changes or debugging steps. Use su - username when you need to test a script or application as a specific non-root user with their full environment. Use sudo -u username command when you need to run a command as another user without switching shells. Use visudo when you need to modify the sudoers configuration. Stay in your normal user shell whenever possible. Running as root increases the risk of accidental system damage.
Run whoami and echo $HOME after every switch. A mismatched environment causes more problems than it solves.