VMware ESXi and vSphere Cluster Management

Customize New Linux User Work Environments with /etc/skel

Learn how /etc/skel supplies default files, directories, and shell settings to new Linux users, including permissions, ownership, testing, and limitations.

/etc/skel is the Linux system skeleton directory. It contains template files and directories that account-creation tools can copy into a newly created user's home directory. A home directory is a user's personal filesystem location, commonly under /home, for personal files and per-user configuration.

Administrators use this mechanism to give new accounts a consistent starting environment. For example, every new user might receive a welcome document, a Documents directory, and initial Bash settings.

How /etc/skel Works

When an account-management command creates a new account and its home directory, it may copy the contents of /etc/skel into that home directory. The source is the system template; the destination is the new user's independent copy.

/etc/skel/                 template source
├── .bashrc                initial Bash configuration
├── .bash_history           optional initial history file
├── README                  visible welcome document
└── Documents/              default directory
    └── starter.txt         optional starter content

new account: testuser
        │
        └── copied into /home/testuser/

The exact behavior depends on the account-creation command, its options, and system defaults. A home directory must generally be created for skeleton content to have a destination. For example, useradd -m requests creation of a home directory on systems where that option is supported.

The skeleton directory is a template, not a live connection. Once files are copied, changes to the source do not automatically flow to users' home directories.

Skeleton Files and the Default User Environment

Skeleton files are the initial per-user files supplied from the skeleton directory. They may be hidden dotfiles, ordinary visible files, or files inside custom directories.

A dotfile is a hidden Unix-style file whose name begins with a period. Dotfiles commonly store per-user configuration. They are not shown by a basic ls command, so use ls -la when inspecting a home directory or /etc/skel.

Administrators can place items such as these beneath /etc/skel:

• Hidden shell configuration files, such as .bashrc.
• Visible guidance files, such as README.
• Directories such as Documents, bin, or a project workspace.
• Non-sensitive starter files inside those directories.

Common Shell-Related Files

.bashrc

.bashrc is a Bash startup configuration file typically read for interactive non-login shells. It can establish aliases, shell options, functions, variables, and other default behavior. A carefully designed template can make a new user's interactive Bash sessions behave consistently.

Shell startup behavior can vary with the way Bash is launched and with distribution-specific configuration. Therefore, a copied .bashrc is an initial configuration, not a guarantee that every shell invocation reads it.

.bash_history

.bash_history is the usual file in which Bash stores a user's command history. A system may include an empty file in /etc/skel, but command history is normally populated and updated through the user's activity. It is different from a static welcome document or configuration file that an administrator deliberately supplies.

Do not place an administrator's command history in the skeleton directory. It could expose commands, paths, or sensitive information to every new account.

Common /etc/skel Content

Adding Custom Content for Future Users

Use administrative privileges to add template content. This example creates an empty visible README with mode 0644, then opens it for editing:

sudo install -m 0644 /dev/null /etc/skel/README
sudo editor /etc/skel/README

Write content that is suitable for all future local users. For example, the README might explain where to find organizational documentation or how to request access. Do not put passwords, private keys, access tokens, host-specific secrets, or unwanted personal data in a skeleton file.

Directories can be added in the same way:

sudo install -d -m 0755 /etc/skel/Documents

Files placed inside that directory are also eligible for copying:

sudo install -m 0644 /dev/null /etc/skel/Documents/starter.txt
sudo editor /etc/skel/Documents/starter.txt

Choose permissions deliberately. A mode such as 0644 allows the owner to read and write while other users can read; 0755 gives the directory owner full access and allows others to enter and read the directory. Use more restrictive modes when the content genuinely requires them, and never assume that permissions make secrets safe to distribute to every new user.

Creating a Test Account

Test the template with a disposable account. The exact command varies by distribution, but this is a common example:

sudo useradd -m testuser
sudo ls -la /home/testuser
sudo stat /home/testuser/README

The -m option requests a home directory. The listing should show copied hidden files as well as visible files such as README. The stat command displays the file's owner, group, mode, and other metadata.

For a directory example, inspect the resulting path:

sudo ls -la /home/testuser/Documents
sudo stat /home/testuser/Documents

After creation, the copied files are normally owned by testuser, not by root. Ownership is the user and group identity associated with a file and is part of how Linux decides who can control it. Because the files are the new user's copies, that user can read, modify, or remove them according to the resulting permissions.

Ownership and User Control

There are two separate objects:

• /etc/skel/README is the central administrator-controlled template.
• /home/testuser/README is an independent copy belonging to the new account.

Editing the template does not edit the copied file. Likewise, a user deleting their own README does not delete the template or affect other users. This separation lets users personalize their environments after account creation.

Effect on Existing Accounts

Changes to /etc/skel apply only when a later account is created and its home directory is populated from the template. They do not automatically add, update, or remove files for existing users.

If existing accounts must be standardized, use a separate, deliberate administrative process. That process might copy a reviewed file, update a configuration-management policy, or ask users before replacing personal settings. Avoid overwriting user-customized files without a defined change plan and backup strategy.

Account-Creation Details That Affect Copying

/etc/skel is associated with tools such as useradd and distribution-specific account-management commands. Copying can be affected by:

• Whether the command creates a home directory.
• Command options that select or disable skeleton copying.
• System defaults and account-management configuration.
• A different configured skeleton directory.
• Permissions or ownership rules applied during account creation.

Do not assume that every account type uses the same process. System accounts, service accounts, externally managed accounts, or accounts created without home directories may not receive the expected files.

Troubleshooting

A new user did not receive expected files

• Inspect the template, including hidden entries: sudo ls -la /etc/skel.
• Confirm that the expected path is actually beneath /etc/skel, not merely in a similarly named directory.
• Confirm that the user's home directory exists: getent passwd testuser and sudo ls -ld /home/testuser.
• Review the account-creation command and relevant system defaults. The command may have been run without a home-directory option, or it may use another skeleton directory.
• Create a fresh disposable test account after confirming the template contents. A template change cannot repair an account that already exists.

An existing user did not receive a new README or changed .bashrc

This is expected. The user existed before the skeleton change, and /etc/skel is not a synchronization mechanism. Confirm the account's creation time relative to the template change, then use a separately planned administrative or configuration-management action if existing users must be updated.

A copied file has unexpected access behavior

• Compare the source and destination with stat /etc/skel/README and stat /home/testuser/README.
• Check the owner, group, and mode on both the file and its parent directories.
• Consider whether the account-creation process applied ownership or permission defaults.
• Adjust the template permissions and test again with a new account. Do not use broadly readable permissions for confidential content.

Exam-Relevant Points

• /etc/skel is a template directory for new user home directories.
• Files and directories beneath it can be copied into a new user's home directory.
• Dotfiles commonly provide initial per-user shell and application configuration.
• .bashrc configures typical interactive non-login Bash behavior; .bash_history stores Bash history and is normally updated by user activity.
• Copied files normally become owned by the new user, who can modify or remove them.
• Changing /etc/skel affects future account creation, not existing home directories.
• Copying depends on account-creation options, system defaults, and whether a home directory is created.
• Skeleton content must not contain private credentials, secrets, or unwanted user data.

For related account and environment administration, continue with Linux user work-environment customization.