Linux online course

Customize New Linux User Environments with /etc/skel

Learn how /etc/skel supplies default files and directories to new Linux user home directories, including Bash templates, testing, permissions, and limitations.

When a Linux administrator creates a local user account, the new account may need more than a username, UID, GID, password, and home directory. It may also need a README, standard directories, shell preferences, or safe configuration templates.

Linux commonly uses /etc/skel to provide this starting environment. Files and directories in this location can be copied into the home directory when a new account is created.

Why provide a default user environment?

A consistent starting environment reduces setup work and gives users useful information immediately after their first login. An organization might provide:

  • A README explaining local policies, support contacts, or first steps.
  • A standard directory layout such as projects, documents, or bin.
  • Shell preferences, aliases, or environment variables.
  • Configuration templates for approved, non-sensitive tools.

These are system-provided starting files. They are copied when the account's home directory is initialized. Afterward, the user may create additional files, change the templates, or remove them. A skeleton file is not a permanent replacement for user-created configuration.

What is /etc/skel?

/etc/skel is the conventional skeleton-directory location used by Linux account-creation tools. A skeleton directory is a source tree containing starter files and directories for new home directories.

For example, this source tree:

/etc/skel/README
/etc/skel/.bashrc
/etc/skel/projects/
/etc/skel/bin/

can result in corresponding entries in a newly created home directory:

/home/alex/README
/home/alex/.bashrc
/home/alex/projects/
/home/alex/bin/

Nested directory structure is preserved. If /etc/skel/projects/examples/sample.txt exists, the account-creation process can create projects/examples/sample.txt beneath the new user's home directory.

Important terms

  • Home directory: A user's personal filesystem location, commonly under /home.
  • Skeleton files: Starter files and directories supplied to a new account when its home directory is created.
  • Dotfile: A hidden Unix file whose name begins with a period, such as .bashrc.
  • UID: The numeric user identifier associated with an account.
  • GID: The numeric group identifier associated with a group.
  • Ownership: The filesystem association of a file with a user and group, which affects access control.

Skeleton files: hidden and visible content

Dotfiles are commonly used in /etc/skel because many per-user configuration files are hidden by convention. The -a option is needed to see them with ls.

Skeleton content does not have to be hidden. Ordinary files such as README and directories such as projects/ are valid skeleton content too.

Common /etc/skel Template Content

Template path | Typical purpose | Visible or hidden | Notes and cautions

/etc/skel/.bashrc | Interactive Bash aliases, variables, and settings | Hidden | Keep changes documented and safe; it applies to users whose sessions read this file.

/etc/skel/README | Welcome message, policies, or first-login instructions | Visible | Use plain, non-confidential information.

/etc/skel/bin/ | Personal command or script directory | Visible directory | Include only reviewed starter files and suitable permissions.

/etc/skel/projects/ | Standard project workspace | Visible directory | The directory hierarchy is reproduced in new home directories.

Common shell-related dotfiles

.bashrc

.bashrc is a Bash initialization file commonly read for interactive, non-login Bash shells. It is often used for aliases, shell options, functions, and environment-related defaults.

A safe template should be clear and portable. For example, an administrator might add a documented alias:

# Organization-approved convenience alias
alias ll='ls -alF'

Whether this takes effect depends on the user's shell and session type. Bash startup behavior differs between interactive, login, graphical, and noninteractive sessions. A user's Bash environment may also include other startup files.

.bash_history

.bash_history commonly stores a user's command history. Bash normally creates and updates it as the user works, so it is usually not a useful shared skeleton template. Pre-populating a history file can be confusing and may expose commands that should not be copied to users.

Startup-file names and processing rules vary by shell and distribution. Bash files do not automatically configure users running shells such as Zsh, Fish, or another configured login shell.

Adding organization-specific defaults

Only place content in /etc/skel that every relevant new user may safely receive. A welcome document is a simple example:

sudo sh -c 'printf "%s\n" "Welcome to this system." > /etc/skel/README'
sudo chmod 644 /etc/skel/README

You can create a standard directory layout with:

sudo mkdir -p /etc/skel/projects
sudo chmod 755 /etc/skel/projects

You may also place a reviewed, non-sensitive starter file inside the directory. Inspect existing templates before changing them, especially .bashrc, because a distribution may already provide important defaults.

Never put confidential data in /etc/skel. This includes private keys, passwords, access tokens, API credentials, personal data, and machine-specific secrets. Anyone receiving a new account may receive copied skeleton content, and the source directory itself requires careful administrative protection.

When does copying occur?

Skeleton content is applied when an account-creation process creates and initializes a home directory. Adding a file to /etc/skel does not retroactively add that file to existing users.

Effects of Changing /etc/skel

Account state | Receives newly added skeleton content? | Required action

Account created after the change | Usually yes, if its home directory is created using the configured skeleton directory | Create the account with the appropriate home-directory and skeleton options.

Account that existed before the change | No | Use a separate, deliberate deployment or migration process.

Account created without a home directory | No initialized home content at creation time | Create and populate a home directory according to local policy, or recreate the account carefully.

The exact result depends on the account-creation tool and its options. The tool must create a home directory and use the intended skeleton directory. A command that creates only an account record may not copy anything.

Ownership and user control

The files in /etc/skel are administrator-maintained templates. After copying, the resulting files are normally owned by the new user and the user's group, rather than remaining owned by the administrator who owns the source templates.

For example, a source file may be owned by root, while the copied file becomes owned by the account's UID and GID. Permissions, local policy, and the account-creation process affect the final mode.

Users can normally edit, rename, or remove copied files because they control their home directories. Other permissions, ACLs, immutable attributes, or organizational policy can change that behavior. A skeleton file is therefore an initial suggestion, not a guaranteed ongoing policy control.

Account-creation tools and skeleton behavior

Account Creation Tool Considerations

Tool or mechanism | Home-directory behavior | Skeleton-directory considerations

useradd | A low-level local-account command; use -m when a home directory should be created on systems that support this behavior | Defaults and options determine whether a home is created and which skeleton path is used.

adduser | A distribution-specific, often interactive frontend | It may apply distribution policies and defaults different from a direct useradd command.

Distribution or site-specific account provisioning | May create users through scripts, PAM-related setup, centralized identity, or another service | Verify whether the mechanism creates local homes and copies the intended skeleton tree.

Where supported, inspect useradd defaults with:

sudo useradd -D

The configured skeleton path can be influenced by defaults or command options. Do not assume every account-creation workflow uses /etc/skel.

Practical workflow: create and verify a test account

Use a disposable account to verify templates before applying them to real users.

  1. Inspect the skeleton tree, including hidden entries:
sudo ls -la /etc/skel
  1. Review the source file and directory permissions. Add only safe content.
  2. Create a test account with a home directory:
sudo useradd -m testskel
sudo passwd testskel

On systems with different local policy, use the distribution's normal account-creation tool. Confirm its home-directory and skeleton settings first.

  1. Inspect the new home directory, including dotfiles:
sudo ls -la /home/testskel
sudo stat -c '%U:%G %a %n' /home/testskel/README

Check that the expected README, directories, and shell files exist. The stat command displays owner, group, permissions, and path. Compare the source and result if permissions look unexpected.

  1. After testing, remove the disposable account and its home directory:
sudo userdel -r testskel

Troubleshooting

A new user does not have the expected templates

  • The account may have been created without a home directory.
  • A different utility or provisioning system may have been used.
  • The configured skeleton directory may not be /etc/skel.
  • The template may have been added after the account was created.

Inspect the account's home-directory setting and the command or service that created it. Run useradd -D where supported, then compare /etc/skel with the new home directory.

An existing user did not receive a new file

This is expected. Skeleton content is applied during new home-directory creation only. Deploy the file separately to existing accounts after deciding its ownership, permissions, overwrite policy, and handling of user customizations.

Ownership or permissions are unexpected

Use ls -l and stat on both the source and copied files. The source mode may be unsuitable, a local umask may affect creation, or a post-creation script may have changed the result. A disposable test account helps isolate the cause.

A shell customization does not take effect

  • The user may not be running Bash.
  • The session may not read .bashrc.
  • The session type may be login, graphical, or noninteractive.
  • A later startup file may override the setting.

Check the user's login shell, identify the session type, and review the applicable shell startup-file order. The full path of a command can also help verify which executable a shell is using.

Scope and limitations

/etc/skel initializes files; it is not continuous configuration management. Changes made later do not automatically synchronize existing home directories, and users can normally customize or delete the copied files.

For existing accounts, use a separate deliberate rollout such as a reviewed administrative script, configuration-management policy, or user-by-user migration. Preserve ownership, permissions, local changes, and confidential-data rules during that process.

The complete workflow may also be affected by local account tools, PAM setup, centralized identity systems, distribution defaults, login managers, and site-specific provisioning. Test the actual mechanism used on your systems.

Exam-relevant notes

  • /etc/skel contains templates for new user home directories.
  • Skeleton content can include hidden dotfiles, visible files, and nested directories.
  • Copying normally occurs when a home directory is created, not whenever a user logs in.
  • Changing /etc/skel does not update existing users.
  • The copied files normally become owned by the new user, while source templates have their own administrator-controlled ownership.
  • .bashrc is commonly used for interactive Bash settings; .bash_history is normally generated and maintained by Bash.
  • Account-creation options and tools determine whether a home directory is created and which skeleton directory is used.