12/27/2021

Run Docker As Sudo

16
  1. Run Docker Without Sudo Ubuntu 20.04
  2. Run Docker As Sudo User
  3. Run Docker As Sudo Mysql
-->

Run Docker Without Sudo Centos; In most cases, you will only interact with the Docker CLI. However, running an application with Docker means that you have to run the Docker Daemon with root privileges. It actually binds to a Unix socket instead of a TCP port. Run sudo command with non-root user in Docker container. Ask Question Asked 4 years, 5 months ago. Active 1 year, 7 months ago. Viewed 46k times. If not, Do the following steps to create docker group and run docker without sudo. First, Create the docker group: sudo groupadd docker. Then, Restart the docker service. (This is important): systemctl restart docker. Now, you can add the non root user to the docker group, (Replace the 'username' with actual username): gpasswd -a username docker. $ sudo docker stop 0ddfa81c5779 OR $ sudo docker stop elasticshirley. A more better way, so that you don’t have to remember the container ID would be to define a unique name for each container you create by using the -name option as shown. $ docker run -name myname centos cat /etc/issue 18. Well if you're using docker in CI and need to test certain commands being run as a regular user then this is the way. For example, on my machine, I am the USER=emmanuel. I don't have root privileges and when I need to install something, I do sudo apt-get install and enter my password to give me su access.

Applies to: SQL Server (all supported versions) - Linux

Note

The examples shown below use the docker.exe but most of these commands also work with Podman. It provides the CLI similar to Docker container Engine. You can read more about podman here.

In this quickstart, you use Docker to pull and run the SQL Server 2017 container image, mssql-server-linux. Then connect with sqlcmd to create your first database and run queries.

Tip

If you want to run SQL Server 2019 containers, see the SQL Server 2019 version of this article.

Note

  • Starting with SQL Server 2019 CU3, Ubuntu 18.04 is supported.
  • Starting with SQL Server 2019 CU10, Ubuntu 20.04 is supported.

In this quickstart, you use Docker to pull and run the SQL Server 2019 container image, mssql-server. Then connect with sqlcmd to create your first database and run queries.

Tip

This quickstart creates SQL Server 2019 containers. If you prefer to create SQL Server 2017 containers, see the SQL Server 2017 version of this article.

This image consists of SQL Server running on Linux based on Ubuntu 20.04. It can be used with the Docker Engine 1.8+ on Linux or on Docker for Mac/Windows. This quickstart specifically focuses on using the SQL Server on Linux image. The Windows image is not covered, but you can learn more about it on the mssql-server-windows-developer Docker Hub page.

Prerequisites

  • Docker Engine 1.8+ on any supported Linux distribution or Docker for Mac/Windows. For more information, see Install Docker. For more information on hardware requirements and processor support, see SQL Server 2019: Hardware and software requirements.
  • Docker overlay2 storage driver. This is the default for most users. If you find that you are not using this storage provider and need to change, see the instructions and warnings in the docker documentation for configuring overlay2.
  • Minimum of 2 GB of disk space.
  • Minimum of 2 GB of RAM.
  • System requirements for SQL Server on Linux.

Pull and run the 2017 container image

Before starting the following steps, make sure that you have selected your preferred shell (bash, PowerShell, or cmd) at the top of this article.

  1. Pull the SQL Server 2017 Linux container image from Microsoft Container Registry.

    Tip

    If you want to run SQL Server 2019 containers, see the SQL Server 2019 version of this article.

    The previous command pulls the latest SQL Server 2017 container image. If you want to pull a specific image, you add a colon and the tag name (for example, mcr.microsoft.com/mssql/server:2017-GA-ubuntu). To see all available images, see the mssql-server Docker hub page.

    For the bash commands in this article, sudo is used. On macOS, sudo might not be required. On Linux, if you do not want to use sudo to run Docker, you can configure a docker group and add users to that group. For more information, see Post-installation steps for Linux.

  2. To run the container image with Docker, you can use the following command from a bash shell (Linux/macOS) or elevated PowerShell command prompt.

    Note

    If you are using PowerShell Core, replace the double quotes with single quotes.

    Note

    The password should follow the SQL Server default password policy, otherwise the container can not setup SQL server and will stop working. By default, the password must be at least 8 characters long and contain characters from three of the following four sets: Uppercase letters, Lowercase letters, Base 10 digits, and Symbols. You can examine the error log by executing the docker logs command.

    By default, this creates a container with the Developer edition of SQL Server 2017. The process for running production editions in containers is slightly different. For more information, see Run production container images.

    The following table provides a description of the parameters in the previous docker run example:

    ParameterDescription
    -e 'ACCEPT_EULA=Y'Set the ACCEPT_EULA variable to any value to confirm your acceptance of the End-User Licensing Agreement. Required setting for the SQL Server image.
    -e 'SA_PASSWORD=<[email protected]>'Specify your own strong password that is at least 8 characters and meets the SQL Server password requirements. Required setting for the SQL Server image.
    -p 1433:1433Map a TCP port on the host environment (first value) with a TCP port in the container (second value). In this example, SQL Server is listening on TCP 1433 in the container and this is exposed to the port, 1433, on the host.
    --name sql1Specify a custom name for the container rather than a randomly generated one. If you run more than one container, you cannot reuse this same name.
    -h sql1Used to explicitly set the container hostname, if you don't specify it, it defaults to the container ID which is a randomly generated system GUID.
    -dRun the container in the background (daemon)
    mcr.microsoft.com/mssql/server:2017-latestThe SQL Server 2017 Linux container image.
  3. To view your Docker containers, use the docker ps command.

    You should see output similar to the following screenshot:

  4. If the STATUS column shows a status of Up, then SQL Server is running in the container and listening on the port specified in the PORTS column. If the STATUS column for your SQL Server container shows Exited, see the Troubleshooting section of the configuration guide. It will be ready for connection, once the SQL Server error logs display the message: SQL Server is now ready for client connections. This is an informational message; no user action is required. You can review the SQL Server error log inside the container using the command:

The -h (host name) parameter as discussed above, changes the internal name of the container to a custom value. This is the name you'll see returned in the following Transact-SQL query:

Setting -h and --name to the same value is a good way to easily identify the target container.

  1. As a final step, change your SA password because the SA_PASSWORD is visible in ps -eax output and stored in the environment variable of the same name. See steps below.

Pull and run the 2019 container image

Before starting the following steps, make sure that you have selected your preferred shell (bash, PowerShell, or cmd) at the top of this article.

  1. Pull the SQL Server 2019 Linux container image from Microsoft Container Registry.

    Note

    If you are using PowerShell Core, replace the double quotes with single quotes.

    Tip

    This quickstart uses the SQL Server 2019 Docker image. If you want to run the SQL Server 2017 image, see the SQL Server 2017 version of this article.

    The previous command pulls the SQL Server 2019 container image based on Ubuntu. To instead use container images based on RedHat, see Run RHEL-based container images. To see all available images, see the mssql-server-linux Docker hub page.

    For the bash commands in this article, sudo is used. On macOS, sudo might not be required. On Linux, if you do not want to use sudo to run Docker, you can configure a docker group and add users to that group. For more information, see Post-installation steps for Linux.

  2. To run the container image with Docker, you can use the following command from a bash shell (Linux/macOS) or elevated PowerShell command prompt.

    Note

    The password should follow the SQL Server default password policy, otherwise the container can not setup SQL server and will stop working. By default, the password must be at least 8 characters long and contain characters from three of the following four sets: Uppercase letters, Lowercase letters, Base 10 digits, and Symbols. You can examine the error log by executing the docker logs command.

    By default, this creates a container with the Developer edition of SQL Server 2019.

    The following table provides a description of the parameters in the previous docker run example:

    ParameterDescription
    -e 'ACCEPT_EULA=Y'Set the ACCEPT_EULA variable to any value to confirm your acceptance of the End-User Licensing Agreement. Required setting for the SQL Server image.
    -e 'SA_PASSWORD=<[email protected]>'Specify your own strong password that is at least 8 characters and meets the SQL Server password requirements. Required setting for the SQL Server image.
    -p 1433:1433Map a TCP port on the host environment (first value) with a TCP port in the container (second value). In this example, SQL Server is listening on TCP 1433 in the container and this is exposed to the port, 1433, on the host.
    --name sql1Specify a custom name for the container rather than a randomly generated one. If you run more than one container, you cannot reuse this same name.
    -h sql1Used to explicitly set the container hostname, if you don't specify it, it defaults to the container ID which is a randomly generated system GUID.
    mcr.microsoft.com/mssql/server:2019-latestThe SQL Server 2019 Ubuntu Linux container image.
  3. To view your Docker containers, use the docker ps command.

    You should see output similar to the following screenshot:

  4. If the STATUS column shows a status of Up, then SQL Server is running in the container and listening on the port specified in the PORTS column. If the STATUS column for your SQL Server container shows Exited, see Troubleshooting SQL Server Docker containers.

The -h (host name) parameter as discussed above, changes the internal name of the container to a custom value. This changes the internal name of the container to a custom value. This is the name you'll see returned in the following Transact-SQL query:

Setting -h and --name to the same value is a good way to easily identify the target container.

  1. As a final step, change your SA password because the SA_PASSWORD is visible in ps -eax output and stored in the environment variable of the same name. See steps below.

Change the SA password

The SA account is a system administrator on the SQL Server instance that gets created during setup. After creating your SQL Server container, the SA_PASSWORD environment variable you specified is discoverable by running echo $SA_PASSWORD in the container. For security purposes, change your SA password.

  1. Choose a strong password to use for the SA user.

  2. Use docker exec to run sqlcmd to change the password using Transact-SQL. In the following example, the old and new passwords are read from user input.

  1. Choose a strong password to use for the SA user.

  2. In the following example, replace the old password, <[email protected]>, and the new password, <[email protected]>, with your own password values.

  1. Choose a strong password to use for the SA user.

  2. In the following example, replace the old password, <[email protected]>, and the new password, <[email protected]>, with your own password values.

Connect to SQL Server

The following steps use the SQL Server command-line tool, sqlcmd, inside the container to connect to SQL Server.

  1. Use the docker exec -it command to start an interactive bash shell inside your running container. In the following example sql1 is name specified by the --name parameter when you created the container.

  2. Once inside the container, connect locally with sqlcmd. Sqlcmd is not in the path by default, so you have to specify the full path.

    Tip

    You can omit the password on the command-line to be prompted to enter it.

  3. If successful, you should get to a sqlcmd command prompt: 1>.

Create and query data

The following sections walk you through using sqlcmd and Transact-SQL to create a new database, add data, and run a query.

Create a new database

The following steps create a new database named TestDB.

  1. From the sqlcmd command prompt, paste the following Transact-SQL command to create a test database:

  2. On the next line, write a query to return the name of all of the databases on your server:

  3. The previous two commands were not executed immediately. Type GO on a new line to execute the previous commands:

Insert data

Next create a new table, Inventory, and insert two new rows.

  1. From the sqlcmd command prompt, switch context to the new TestDB database:

  2. Create new table named Inventory:

  3. Insert data into the new table:

  4. Type GO to execute the previous commands:

Select data

Now, run a query to return data from the Inventory table.

  1. From the sqlcmd command prompt, enter a query that returns rows from the Inventory table where the quantity is greater than 152:

  2. Execute the command:

Exit the sqlcmd command prompt

  1. To end your sqlcmd session, type QUIT:

  2. To exit the interactive command-prompt in your container, type exit. Your container continues to run after you exit the interactive bash shell.

Connect from outside the container

You can also connect to the SQL Server instance on your Docker machine from any external Linux, Windows, or macOS tool that supports SQL connections.

The following steps use sqlcmd outside of your container to connect to SQL Server running in the container. These steps assume that you already have the SQL Server command-line tools installed outside of your container. The same principles apply when using other tools, but the process of connecting is unique to each tool.

  1. Find the IP address for the machine that hosts your container. On Linux, use ifconfig or ip addr. On Windows, use ipconfig.

  2. For this example, install the sqlcmd tool on your client machine. For more information, see Install sqlcmd on Windows or Install sqlcmd on Linux.

  3. Run sqlcmd specifying the IP address and the port mapped to port 1433 in your container. In this example, that is the same port, 1433, on the host machine. If you specified a different mapped port on the host machine, you would use it here. You will also need to open the appropriate inbound port on your firewall to allow the connection.

  4. Run Transact-SQL commands. When finished, type QUIT.

Other common tools to connect to SQL Server include:

Remove your container

If you want to remove the SQL Server container used in this tutorial, run the following commands:

Warning

Stopping and removing a container permanently deletes any SQL Server data in the container. If you need to preserve your data, create and copy a backup file out of the container or use a container data persistence technique.

Docker demo

After you have tried using the SQL Server container image for Docker, you might want to know how Docker is used to improve development and testing. The following video shows how Docker can be used in a continuous integration and deployment scenario.

Next steps

For a tutorial on how to restore database backup files into a container, see Restore a SQL Server database in a Linux Docker container. Explore other scenarios, such as running multiple containers, data persistence, and troubleshooting.

Also, check out the mssql-docker GitHub repository for resources, feedback, and known issues.

Estimated reading time: 19 minutes

Rootless mode allows running the Docker daemon and containers as a non-rootuser to mitigate potential vulnerabilities in the daemon andthe container runtime.

Rootless mode does not require root privileges even during the installation ofthe Docker daemon, as long as the prerequisites are met.

Rootless mode was introduced in Docker Engine v19.03 as an experimental feature.Rootless mode graduated from experimental in Docker Engine v20.10.

How it works

Rootless mode executes the Docker daemon and containers inside a user namespace.This is very similar to userns-remap mode, except thatwith userns-remap mode, the daemon itself is running with root privileges,whereas in rootless mode, both the daemon and the container are running withoutroot privileges.

Rootless mode does not use binaries with SETUID bits or file capabilities,except newuidmap and newgidmap, which are needed to allow multipleUIDs/GIDs to be used in the user namespace.

Prerequisites

  • You must install newuidmap and newgidmap on the host. These commands are provided by the uidmap package on most distros.

  • /etc/subuid and /etc/subgid should contain at least 65,536 subordinateUIDs/GIDs for the user. In the following example, the user testuser has65,536 subordinate UIDs/GIDs (231072-296607).

Distribution-specific hint

Note: We recommend that you use the Ubuntu kernel.

  • Install dbus-user-session package if not installed. Run sudo apt-get install -y dbus-user-session and relogin.

  • overlay2 storage driver is enabled by default(Ubuntu-specific kernel patch).

  • Known to work on Ubuntu 18.04, 20.04, and 21.04.

  • Install dbus-user-session package if not installed. Run sudo apt-get install -y dbus-user-session and relogin.

  • For Debian 10, add kernel.unprivileged_userns_clone=1 to /etc/sysctl.conf (or/etc/sysctl.d) and run sudo sysctl --system. This step is not required on Debian 11.

  • Installing fuse-overlayfs is recommended. Run sudo apt-get install -y fuse-overlayfs.Using overlay2 storage driver with Debian-specific modprobe option sudo modprobe overlay permit_mounts_in_userns=1 is also possible,however, highly discouraged due to instability.

  • Rootless docker requires version of slirp4netns greater than v0.4.0 (when vpnkit is not installed).Check you have this with

    If you do not have this download and install with sudo apt-get install -y slirp4netns or download the latest release.

  • Installing fuse-overlayfs is recommended. Run sudo pacman -S fuse-overlayfs.

  • Add kernel.unprivileged_userns_clone=1 to /etc/sysctl.conf (or/etc/sysctl.d) and run sudo sysctl --system

  • Installing fuse-overlayfs is recommended. Run sudo zypper install -y fuse-overlayfs.

  • sudo modprobe ip_tables iptable_mangle iptable_nat iptable_filter is required.This might be required on other distros as well depending on the configuration.

  • Known to work on openSUSE 15 and SLES 15.

  • Installing fuse-overlayfs is recommended. Run sudo dnf install -y fuse-overlayfs.

  • You might need sudo dnf install -y iptables.

  • Known to work on CentOS 8, RHEL 8, and Fedora 34.

  • Add user.max_user_namespaces=28633 to /etc/sysctl.conf (or /etc/sysctl.d) and run sudo sysctl --system.

  • systemctl --user does not work by default. Run dockerd-rootless.sh directly without systemd.

Known limitations

  • Only the following storage drivers are supported:
    • overlay2 (only if running with kernel 5.11 or later, or Ubuntu-flavored kernel)
    • fuse-overlayfs (only if running with kernel 4.18 or later, and fuse-overlayfs is installed)
    • btrfs (only if running with kernel 4.18 or later, or ~/.local/share/docker is mounted with user_subvol_rm_allowed mount option)
    • vfs
  • Cgroup is supported only when running with cgroup v2 and systemd. See Limiting resources.
  • Following features are not supported:
    • AppArmor
    • Checkpoint
    • Overlay network
    • Exposing SCTP ports
  • To use the ping command, see Routing ping packets.
  • To expose privileged TCP/UDP ports (< 1024), see Exposing privileged ports.
  • IPAddress shown in docker inspect and is namespaced inside RootlessKit’s network namespace.This means the IP address is not reachable from the host without nsenter-ing into the network namespace.
  • Host network (docker run --net=host) is also namespaced inside RootlessKit.
  • NFS mounts as the docker “data-root” is not supported. This limitation is not specific to rootless mode.

Install

Note

If the system-wide Docker daemon is already running, consider disabling it:$ sudo systemctl disable --now docker.service docker.socket

If you installed Docker 20.10 or later with RPM/DEB packages, you should have dockerd-rootless-setuptool.sh in /usr/bin.

Run dockerd-rootless-setuptool.sh install as a non-root user to set up the daemon:

If dockerd-rootless-setuptool.sh is not present, you may need to install the docker-ce-rootless-extras package manually, e.g.,

If you do not have permission to run package managers like apt-get and dnf,consider using the installation script available at https://get.docker.com/rootless.Since static packages are not available for s390x, hence it is not supported for s390x.

The binaries will be installed at ~/bin.

See Troubleshooting if you faced an error.

Uninstall

To remove the systemd service of the Docker daemon, run dockerd-rootless-setuptool.sh uninstall:

Unset environment variables PATH and DOCKER_HOST if you have added them to ~/.bashrc.

To remove the data directory, run rootlesskit rm -rf ~/.local/share/docker.

To remove the binaries, remove docker-ce-rootless-extras package if you installed Docker with package managers.If you installed Docker with https://get.docker.com/rootless (Install without packages),remove the binary files under ~/bin:

Usage

Daemon

The systemd unit file is installed as ~/.config/systemd/user/docker.service.

Use systemctl --user to manage the lifecycle of the daemon:

To launch the daemon on system startup, enable the systemd service and lingering:

Starting Rootless Docker as a systemd-wide service (/etc/systemd/system/docker.service)is not supported, even with the User= directive.

To run the daemon directly without systemd, you need to run dockerd-rootless.sh instead of dockerd.

The following environment variables must be set:

  • $HOME: the home directory
  • $XDG_RUNTIME_DIR: an ephemeral directory that is only accessible by the expected user, e,g, ~/.docker/run.The directory should be removed on every host shutdown.The directory can be on tmpfs, however, should not be under /tmp.Locating this directory under /tmp might be vulnerable to TOCTOU attack.

Remarks about directory paths:

  • The socket path is set to $XDG_RUNTIME_DIR/docker.sock by default.$XDG_RUNTIME_DIR is typically set to /run/user/$UID.
  • The data dir is set to ~/.local/share/docker by default.The data dir should not be on NFS.
  • The daemon config dir is set to ~/.config/docker by default.This directory is different from ~/.docker that is used by the client.

Client

You need to specify either the socket path or the CLI context explicitly.

To specify the socket path using $DOCKER_HOST:

To specify the CLI context using docker context:

Best practices

Rootless Docker in Docker

To run Rootless Docker inside “rootful” Docker, use the docker:<version>-dind-rootlessimage instead of docker:<version>-dind.

The docker:<version>-dind-rootless image runs as a non-root user (UID 1000).However, --privileged is required for disabling seccomp, AppArmor, and mountmasks.

Expose Docker API socket through TCP

To expose the Docker API socket through TCP, you need to launch dockerd-rootless.shwith DOCKERD_ROOTLESS_ROOTLESSKIT_FLAGS='-p 0.0.0.0:2376:2376/tcp'.

Expose Docker API socket through SSH

To expose the Docker API socket through SSH, you need to make sure $DOCKER_HOSTis set on the remote host.

Routing ping packets

On some distributions, ping does not work by default.

Add net.ipv4.ping_group_range = 0 2147483647 to /etc/sysctl.conf (or/etc/sysctl.d) and run sudo sysctl --system to allow using ping.

Sudo

Exposing privileged ports

To expose privileged ports (< 1024), set CAP_NET_BIND_SERVICE on rootlesskit binary.

Or add net.ipv4.ip_unprivileged_port_start=0 to /etc/sysctl.conf (or/etc/sysctl.d) and run sudo sysctl --system.

Limiting resources

Limiting resources with cgroup-related docker run flags such as --cpus, --memory, --pids-limitis supported only when running with cgroup v2 and systemd.See Changing cgroup version to enable cgroup v2.

If docker info shows none as Cgroup Driver, the conditions are not satisfied.When these conditions are not satisfied, rootless mode ignores the cgroup-related docker run flags.See Limiting resources without cgroup for workarounds.

If docker info shows systemd as Cgroup Driver, the conditions are satisfied.However, typically, only memory and pids controllers are delegated to non-root users by default.

To allow delegation of all controllers, you need to change the systemd configuration as follows:

Note

Delegating cpuset requires systemd 244 or later.

Limiting resources without cgroup

Even when cgroup is not available, you can still use the traditional ulimit and cpulimit,though they work in process-granularity rather than in container-granularity,and can be arbitrarily disabled by the container process.

For example:

  • To limit CPU usage to 0.5 cores (similar to docker run --cpus 0.5):docker run <IMAGE> cpulimit --limit=50 --include-children <COMMAND>
  • To limit max VSZ to 64MiB (similar to docker run --memory 64m):docker run <IMAGE> sh -c 'ulimit -v 65536; <COMMAND>'

  • To limit max number of processes to 100 per namespaced UID 2000(similar to docker run --pids-limit=100):docker run --user 2000 --ulimit nproc=100 <IMAGE> <COMMAND>

Troubleshooting

Errors when starting the Docker daemon

[rootlesskit:parent] error: failed to start the child: fork/exec /proc/self/exe: operation not permitted

This error occurs mostly when the value of /proc/sys/kernel/unprivileged_userns_clone is set to 0:

To fix this issue, add kernel.unprivileged_userns_clone=1 to/etc/sysctl.conf (or /etc/sysctl.d) and run sudo sysctl --system.

[rootlesskit:parent] error: failed to start the child: fork/exec /proc/self/exe: no space left on device

This error occurs mostly when the value of /proc/sys/user/max_user_namespaces is too small:

To fix this issue, add user.max_user_namespaces=28633 to/etc/sysctl.conf (or /etc/sysctl.d) and run sudo sysctl --system.

[rootlesskit:parent] error: failed to setup UID/GID map: failed to compute uid/gid map: No subuid ranges found for user 1001 (“testuser”)

This error occurs when /etc/subuid and /etc/subgid are not configured. See Prerequisites.

could not get XDG_RUNTIME_DIR

This error occurs when $XDG_RUNTIME_DIR is not set.

On a non-systemd host, you need to create a directory and then set the path:

Note:You must remove the directory every time you log out.

On a systemd host, log into the host using pam_systemd (see below).The value is automatically set to /run/user/$UID and cleaned up on every logout.

systemctl --user fails with “Failed to connect to bus: No such file or directory”

This error occurs mostly when you switch from the root user to an non-root user with sudo:

Instead of sudo -iu <USERNAME>, you need to log in using pam_systemd. For example:

  • Log in through the graphic console
  • ssh <USERNAME>@localhost
  • machinectl shell <USERNAME>@

The daemon does not start up automatically

You need sudo loginctl enable-linger $(whoami) to enable the daemon to startup automatically. See Usage.

iptables failed: iptables -t nat -N DOCKER: Fatal: can’t open lock file /run/xtables.lock: Permission denied

This error may happen with an older version of Docker when SELinux is enabled on the host.

The issue has been fixed in Docker 20.10.8.A known workaround for older version of Docker is to run the following commands to disable SELinux for iptables:

docker pull errors

docker: failed to register layer: Error processing tar file(exit status 1): lchown <FILE>: invalid argument

This error occurs when the number of available entries in /etc/subuid or/etc/subgid is not sufficient. The number of entries required vary acrossimages. However, 65,536 entries are sufficient for most images. SeePrerequisites.

docker: failed to register layer: ApplyLayer exit status 1 stdout: stderr: lchown <FILE>: operation not permitted

This error occurs mostly when ~/.local/share/docker is located on NFS.

A workaround is to specify non-NFS data-root directory in ~/.config/docker/daemon.json as follows:

docker run errors

docker: Error response from daemon: OCI runtime create failed: ...: read unix @->/run/systemd/private: read: connection reset by peer: unknown.

This error occurs on cgroup v2 hosts mostly when the dbus daemon is not running for the user.

To fix the issue, run sudo apt-get install -y dbus-user-session or sudo dnf install -y dbus-daemon, and then relogin.

If the error still occurs, try running systemctl --user enable --now dbus (without sudo).

--cpus, --memory, and --pids-limit are ignored

This is an expected behavior on cgroup v1 mode.To use these flags, the host needs to be configured for enabling cgroup v2.For more information, see Limiting resources.

Networking errors

docker run -p fails with cannot expose privileged port

docker run -p fails with this error when a privileged port (< 1024) is specified as the host port.

When you experience this error, consider using an unprivileged port instead. For example, 8080 instead of 80.

To allow exposing privileged ports, see Exposing privileged ports.

ping doesn’t work

Ping does not work when /proc/sys/net/ipv4/ping_group_range is set to 1 0:

For details, see Routing ping packets.

IPAddress shown in docker inspect is unreachable

This is an expected behavior, as the daemon is namespaced inside RootlessKit’snetwork namespace. Use docker run -p instead.

--net=host doesn’t listen ports on the host network namespace

This is an expected behavior, as the daemon is namespaced inside RootlessKit’snetwork namespace. Use docker run -p instead.

Network is slow

Docker with rootless mode uses slirp4netns as the default network stack if slirp4netns v0.4.0 or later is installed.If slirp4netns is not installed, Docker falls back to VPNKit.

Command

Installing slirp4netns may improve the network throughput.See RootlessKit documentation for the benchmark result.

Run docker as sudo file

Also, changing MTU value may improve the throughput.The MTU value can be specified by creating ~/.config/systemd/user/docker.service.d/override.conf with the following content:

And then restart the daemon:

docker run -p does not propagate source IP addresses

This is because Docker with rootless mode uses RootlessKit’s builtin port driver by default.

The source IP addresses can be propagated by creating ~/.config/systemd/user/docker.service.d/override.conf with the following content:

And then restart the daemon:

Run Docker Without Sudo Ubuntu 20.04

Note that this configuration decreases throughput.See RootlessKit documentation for the benchmark result.

Tips for debugging

Entering into dockerd namespaces

The dockerd-rootless.sh script executes dockerd in its own user, mount, and network namespaces.

Run Docker As Sudo User

For debugging, you can enter the namespaces by runningnsenter -U --preserve-credentials -n -m -t $(cat $XDG_RUNTIME_DIR/docker.pid).

Run Docker As Sudo Mysql

security, namespaces, rootless
  • Most Viewed News

    • Microsoft Word For Apple Free
    • Hackintosh Software Download
    • Google Calendar App Macos
    • Google Meet In Macbook Air
    • Google Maps For Imac