Skip to content

Linux post-installation steps for Docker Engine

These optional post-installation procedures describe how to configure your Linux host machine to work better with Docker.

Manage Docker as a non-root user

The Docker daemon binds to a Unix socket, not a TCP port. By default it's the root user that owns the Unix socket, and other users can only access it using sudo. The Docker daemon always runs as the root user.

If you don't want to preface the docker command with sudo, create a Unix group called docker and add users to it. When the Docker daemon starts, it creates a Unix socket accessible by members of the docker group. On some Linux distributions, the system automatically creates this group when installing Docker Engine using a package manager. In that case, there is no need for you to manually create the group.

Warning

The docker group grants root-level privileges to the user. For details on how this impacts security in your system, see Docker Daemon Attack Surface.

The Docker socket is root, wherever it goes

Anyone who can talk to /var/run/docker.sock can run docker run -v /:/host ... and own the machine, with no password and no sudo log. That applies to:

  • users in the docker group (treat membership like passwordless sudo and keep the list short),
  • containers that mount the socket (autoheal, Dozzle, Homepage's Docker widget, deploy agents, Watchtower-style updaters). Mounting it :ro does not help: read-only only stops the socket file being replaced, the API behind it is still fully writable.

Only give the socket to containers that need it, keep those images pinned and from projects you trust, and for tools that only read (dashboards, log viewers) put a filtering proxy such as docker-socket-proxy in between with only the API sections they need enabled.

Note

To run Docker without root privileges, see Run the Docker daemon as a non-root user (Rootless mode).

To create the docker group and add your user:

  1. Create the docker group.
 sudo groupadd docker
  1. Add your user to the docker group.
 sudo usermod -aG docker $USER
  1. Log out and log back in so that your group membership is re-evaluated.

If you're running Linux in a virtual machine, it may be necessary to restart the virtual machine for changes to take effect.

You can also run the following command to activate the changes to groups:

 newgrp docker
  1. Verify that you can run docker commands without sudo.
 docker run hello-world

This command downloads a test image and runs it in a container. When the container runs, it prints a message and exits.

If you initially ran Docker CLI commands using sudo before adding your user to the docker group, you may see the following error:

WARNING: Error loading config file: /home/user/.docker/config.json -
stat /home/user/.docker/config.json: permission denied

This error indicates that the permission settings for the ~/.docker/ directory are incorrect, due to having used the sudo command earlier.

To fix this problem, either remove the ~/.docker/ directory (it's recreated automatically, but any custom settings are lost), or change its ownership and permissions using the following commands:

 sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
 sudo chmod g+rwx "$HOME/.docker" -R

Configure Docker to start on boot with systemd

Many modern Linux distributions use systemd to manage which services start when the system boots. On Debian and Ubuntu, the Docker service starts on boot by default. To automatically start Docker and containerd on boot for other Linux distributions using systemd, run the following commands:

 sudo systemctl enable docker.service
 sudo systemctl enable containerd.service

To stop this behavior, use disable instead.

 sudo systemctl disable docker.service
 sudo systemctl disable containerd.service

You can use systemd unit files to configure the Docker service on startup, for example to add an HTTP proxy, set a different directory or partition for the Docker runtime files, or other customizations. For an example, see Configure the daemon to use a proxy.

The daemon.json I use

All my servers get the same /etc/docker/daemon.json:

/etc/docker/daemon.json
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  },
  "dns": ["192.168.1.1"],
  "shutdown-timeout": 60
}
Key Why
log-opts max-size / max-file Caps each container's log at 3 × 10 MB. Without it, json-file logs grow until the disk fills. docker logs and log viewers like Dozzle keep working.
dns Point containers' DNS at your router/resolver (replace 192.168.1.1). Without it, Docker copies the host's /etc/resolv.conf once, when each container starts: a container that starts during a boot-time DNS gap, or after a VPN/Tailscale client rewrites the host's resolv.conf, keeps the broken copy until it's restarted.
shutdown-timeout On reboot or daemon stop, containers get 60 s instead of 15 s to exit cleanly. Databases (Postgres, MongoDB, SQLite apps) need it to flush instead of being killed mid-write.

Apply it:

# Validate first: a broken daemon.json stops dockerd from starting at all
sudo dockerd --validate --config-file=/etc/docker/daemon.json

# dns / log-driver changes need a full restart (restarts every container)
sudo systemctl restart docker

# shutdown-timeout (and a few other keys) can be reloaded without restarting containers
sudo kill -SIGHUP "$(pidof dockerd)"

Log options only apply to new containers

Existing containers keep the logging config they were created with. docker compose up -d --force-recreate (or the next deploy that recreates them) picks up the new defaults.

Lessons learned

The dns key came out of real incidents: containers that couldn't resolve names after a reboot and stale DNS inside containers. If your resolver returns IPv6 addresses but the host has no IPv6 route, read AAAA records with no IPv6 route too.

Configure default logging driver

Docker provides logging drivers for collecting and viewing log data from all containers running on a host. The default logging driver, json-file, writes log data to JSON-formatted files on the host filesystem. Over time, these log files expand in size, leading to potential exhaustion of disk resources.

To avoid issues with overusing disk for log data, consider one of the following options:

To use the json-file driver as the default logging driver, set the log-driver and log-opts keys to appropriate values in the daemon.json file, which is located in /etc/docker/ on Linux hosts or C:\ProgramData\docker\config\ on Windows Server. If the file does not exist, create it first. For more information about configuring Docker using daemon.json, see daemon.json.

The following example sets the log driver to json-file and sets the max-size and max-file options to enable automatic log-rotation.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Note

log-opts configuration options in the daemon.json configuration file must be provided as strings. Boolean and numeric values (such as the value for max-file in the example above) must therefore be enclosed in quotes (").

Restart Docker for the changes to take effect for newly created containers. Existing containers don't use the new logging configuration automatically.

You can set the logging driver for a specific container by using the --log-driver flag to docker container create or docker run:

 docker run \
      --log-driver json-file --log-opt max-size=10m \
      alpine echo hello world

Next steps

  • Compose conventions: pinned tags, healthchecks, autoheal, and validating before deploy.
  • Take a look at the Docker workshop to learn how to build an image and run it as a containerized application.

Sources & further reading