If /home belongs to the users, /etc belongs to the administrator. It is the directory where Linux keeps the configuration that defines how the system and every service running on it behaves. Understanding /etc well is close to a prerequisite for doing any serious system administration, because nearly every troubleshooting session ends with editing something inside it.

What /etc actually contains

The name is a historical artifact. It originally stood for “et cetera,” used for miscellaneous files that did not obviously belong anywhere else in early Unix. Over decades of standardization, its role narrowed and solidified into something precise: system-wide, host-specific configuration, stored as plain text.

ls /etc | wc -l
# often 150-300+ entries on a typical desktop or server

ls /etc | head -20

Everything under /etc is meant to be human-readable and editable with a plain text editor. This is a deliberate design choice inherited from Unix: configuration is not stored in an opaque binary format or a registry, it is text you can cat, grep, and edit with vim or nano.

The files you will touch most often

A handful of files inside /etc come up constantly in day-to-day administration:

/etc/passwd          # user account definitions (username, UID, home dir, shell)
/etc/shadow          # encrypted password hashes, root-readable only
/etc/group           # group definitions and membership
/etc/fstab           # filesystems to mount automatically at boot
/etc/hosts           # local hostname-to-IP mappings, checked before DNS
/etc/hostname        # this machine's hostname
/etc/resolv.conf     # DNS resolver configuration (often auto-managed)
/etc/os-release      # distribution name and version identifiers
/etc/sudoers         # who can run what with sudo (edit only with visudo)
/etc/ssh/sshd_config # SSH server configuration
/etc/crontab         # system-wide scheduled tasks

# Confirm what distribution and version you're running
cat /etc/os-release

# See what's set to mount at boot
cat /etc/fstab

# Check local hostname overrides before DNS is consulted
cat /etc/hosts

Service configuration lives in its own subdirectory

Most installed services keep their configuration in a dedicated subdirectory of /etc named after the package:

/etc/nginx/          # web server config
/etc/apache2/         # (Debian/Ubuntu Apache config path)
/etc/httpd/           # (RHEL/Fedora Apache config path)
/etc/mysql/           # MySQL/MariaDB config
/etc/postgresql/      # PostgreSQL config
/etc/docker/          # Docker daemon config
/etc/systemd/system/  # custom systemd unit files

This pattern scales cleanly: installing a new service adds a new subdirectory rather than dumping more files into a flat, unorganized /etc. It also means you can grep -r inside a specific service’s directory when you know roughly what you are looking for but not the exact filename.

# Search every nginx config file for a setting
grep -rn "server_name" /etc/nginx/

# Check systemd override files for a service
ls /etc/systemd/system/nginx.service.d/ 2>/dev/null

The .d/ directory convention

Many tools support splitting configuration across multiple files inside a directory ending in .d, rather than one giant monolithic file:

/etc/sudoers.d/       # additional sudo rules, included by /etc/sudoers
/etc/cron.d/          # additional scheduled jobs
/etc/nginx/conf.d/    # additional nginx server blocks
/etc/systemd/system/nginx.service.d/  # systemd override snippets

This convention exists for a practical reason: custom rules dropped into a .d/ directory generally survive package updates cleanly, since the package manager only ships and manages the main file, not the contents of the include directory. Editing the main file directly risks having your changes overwritten the next time the package updates.

Editing configuration safely

A few habits make editing /etc much less risky:

# Always back up before editing
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%F)

# Use the dedicated tool where one exists
sudo visudo              # validates /etc/sudoers syntax before saving
sudo visudo -f /etc/sudoers.d/myrules

# Check a service's config syntax before restarting it
sudo nginx -t
sudo apachectl configtest
sudo sshd -t

# Restart only after the syntax check passes
sudo systemctl restart nginx

Skipping the syntax check step is a common way to take down a running service: a single misplaced brace in an nginx config or a typo in sshd_config can prevent the daemon from starting again, and if that daemon happens to be your only way to reach the server (SSH, for instance), the mistake can lock you out entirely. Testing configuration before restarting the service is cheap insurance against that outcome.

What happens to /etc during package updates

Package managers are careful about not blindly overwriting files an administrator has modified:

# Debian/Ubuntu: apt detects local modifications and prompts you
sudo apt upgrade
# "Configuration file '/etc/ssh/sshd_config'
#  ==> Modified (by you or by a script) since installation.
#  What would you like to do about it?"

# Fedora/RHEL: rpm may install the new default alongside yours
ls /etc/ssh/sshd_config*
# sshd_config       <- your edited version, untouched
# sshd_config.rpmnew <- the new default shipped by the update

This is another reason the .d/ convention exists: files you add to an include directory are yours, and package updates generally do not touch them at all, sidestepping the merge conflict entirely.

Finding which package owns a config file

When troubleshooting an unfamiliar file in /etc, it helps to know where it came from:

# Debian/Ubuntu
dpkg -S /etc/nginx/nginx.conf

# Fedora/RHEL
rpm -qf /etc/nginx/nginx.conf

This tells you whether the file is tracked by a package (and therefore has defaults you can restore) or was created manually by a script, a previous administrator, or another piece of software entirely.

Frequently Asked Questions

What does /etc stand for and what is it for?

The name /etc originally came from “et cetera,” a holdover from early Unix when it became a catch-all for files that did not fit elsewhere. Today it has a precise, well-defined purpose: it holds system-wide, host-specific configuration files. Anything that controls how a service, daemon, or the system itself behaves on this particular machine generally lives somewhere under /etc, as plain text files an administrator can read and edit directly.

What are some of the most important files in /etc?

/etc/passwd lists user accounts and their basic properties. /etc/shadow holds encrypted password hashes and is readable only by root. /etc/fstab defines which filesystems mount automatically at boot and where. /etc/hosts maps hostnames to IP addresses locally, bypassing DNS. /etc/hostname sets the machine name. /etc/ssh/sshd_config controls the SSH server. /etc/nginx/ and /etc/apache2/ hold web server configuration on systems running those services.

Is it safe to edit files in /etc directly?

Generally yes, that is exactly what /etc is for, but with two important precautions. First, always back up a config file before changing it, for example with cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak. Second, use the tool designed for a given file where one exists, such as visudo for /etc/sudoers, since it validates syntax before saving and prevents a broken file from locking you out or crashing a service.

What is the difference between /etc and /var for configuration?

/etc holds the configuration you write and rarely changes on its own: settings, credentials, and definitions that an administrator edits deliberately. /var holds data that changes automatically as the system runs: logs, caches, and databases that grow over time without direct editing. A web server’s configuration file lives in /etc/nginx, while the access logs it generates while running live in /var/log/nginx.

How do I find which package a file in /etc came from?

On Debian and Ubuntu, run dpkg -S /etc/path/to/file to see which installed package owns that file. On Fedora and RHEL, use rpm -qf /etc/path/to/file. This is useful when troubleshooting: it tells you whether a configuration file is managed by a package (and might be overwritten on an update) or was created manually by an administrator or a different piece of software.

What happens to my /etc changes when I update a package?

Package managers generally try to preserve local edits. On Debian-based systems, if a configuration file has been modified since installation, apt typically prompts you to keep your version, accept the new one, or view a diff before deciding. On Fedora and RHEL, rpm often installs the new version alongside your modified file with an .rpmnew extension, leaving your edits untouched, and expects you to merge changes manually. This is also why custom rules are often placed in a dedicated .d/ subdirectory (like /etc/sudoers.d/ or /etc/nginx/conf.d/) rather than the main config file, since included directories are less likely to be touched by an update.