{
	"id": "38a12aac-20c7-4e01-bbbc-53838cc16f54",
	"created_at": "2026-04-06T03:37:44.805238Z",
	"updated_at": "2026-04-10T03:22:04.781662Z",
	"deleted_at": null,
	"sha1_hash": "eec77de53538bd545d769b1a7dad39c4b3eb933b",
	"title": "dockerd",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 225090,
	"plain_text": "dockerd\r\nBy Docker Inc\r\nPublished: 2026-03-23 · Archived: 2026-04-06 03:35:06 UTC\r\nOptions with [] may be specified multiple times.\r\ndockerd is the persistent process that manages containers. Docker uses different binaries for the daemon and\r\nclient. To run the daemon you type dockerd .\r\nTo run the daemon with debug output, use dockerd --debug or add \"debug\": true to the daemon.json file.\r\nEnabling experimental features\r\nEnable experimental features by starting dockerd with the --experimental flag or adding\r\n\"experimental\": true to the daemon.json file.\r\nEnvironment variables\r\nThe following list of environment variables are supported by the dockerd daemon. Some of these environment\r\nvariables are supported both by the Docker Daemon and the docker CLI. Refer to Environment variables to\r\nlearn about environment variables supported by the docker CLI.\r\nVariable Description\r\nDOCKER_CERT_PATH\r\nLocation of your authentication keys. This variable is used both by the docker CLI\r\nand the dockerd daemon.\r\nDOCKER_DRIVER The storage driver to use.\r\nDOCKER_RAMDISK If set this disables pivot_root .\r\nDOCKER_TLS_VERIFY\r\nWhen set Docker uses TLS and verifies the remote. This variable is used both by the\r\ndocker CLI and the dockerd daemon.\r\nDOCKER_TMPDIR Location for temporary files created by the daemon.\r\nHTTP_PROXY\r\nProxy URL for HTTP requests unless overridden by NoProxy. See the Go\r\nspecification for details.\r\nHTTPS_PROXY\r\nProxy URL for HTTPS requests unless overridden by NoProxy. See the Go\r\nspecification for details.\r\nMOBY_DISABLE_PIGZ\r\nDisables the use of unpigz to decompress layers in parallel when pulling images,\r\neven if it is installed.\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 1 of 16\n\nVariable Description\r\nNO_PROXY\r\nComma-separated values specifying hosts that should be excluded from proxying.\r\nSee the Go specification for details.\r\nProxy configuration\r\nIf you are behind an HTTP proxy server, for example in corporate settings, you may have to configure the Docker\r\ndaemon to use the proxy server for operations such as pulling and pushing images. The daemon can be configured\r\nin three ways:\r\n1. Using environment variables ( HTTP_PROXY , HTTPS_PROXY , and NO_PROXY ).\r\n2. Using the http-proxy , https-proxy , and no-proxy fields in the daemon configuration file (Docker\r\nEngine version 23.0 or later).\r\n3. Using the --http-proxy , --https-proxy , and --no-proxy command-line options. (Docker Engine\r\nversion 23.0 or later).\r\nThe command-line and configuration file options take precedence over environment variables. Refer to control\r\nand configure Docker with systemd to set these environment variables on a host using systemd .\r\nDaemon socket option\r\nThe Docker daemon can listen for Docker Engine API requests via three different types of Socket: unix , tcp ,\r\nand fd .\r\nBy default, a unix domain socket (or IPC socket) is created at /var/run/docker.sock , requiring either root\r\npermission, or docker group membership.\r\nIf you need to access the Docker daemon remotely, you need to enable the tcp Socket. When using a TCP socket,\r\nthe Docker daemon provides un-encrypted and un-authenticated direct access to the Docker daemon by default.\r\nYou should secure the daemon either using the built in HTTPS encrypted socket, or by putting a secure web proxy\r\nin front of it. You can listen on port 2375 on all network interfaces with -H tcp://0.0.0.0:2375 , or on a\r\nparticular network interface using its IP address: -H tcp://192.168.59.103:2375 . It is conventional to use port\r\n2375 for un-encrypted, and port 2376 for encrypted communication with the daemon.\r\nIf you're using an HTTPS encrypted socket, keep in mind that only TLS version 1.0 and higher is\r\nsupported. Protocols SSLv3 and below are not supported for security reasons.\r\nOn systemd based systems, you can communicate with the daemon via systemd socket activation, with dockerd -\r\nH fd:// . Using fd:// works for most setups, but you can also specify individual sockets: dockerd -H fd://3 .\r\nIf the specified socket activated files aren't found, the daemon exits. You can find examples of using systemd\r\nsocket activation with Docker and systemd in the Docker source tree.\r\nYou can configure the Docker daemon to listen to multiple sockets at the same time using multiple -H options:\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 2 of 16\n\nThe example below runs the daemon listening on the default Unix socket, and on 2 specific IP addresses on this\r\nhost:\r\nThe Docker client honors the DOCKER_HOST environment variable to set the -H flag for the client. Use one of the\r\nfollowing commands:\r\nSetting the DOCKER_TLS_VERIFY environment variable to any value other than the empty string is equivalent to\r\nsetting the --tlsverify flag. The following are equivalent:\r\nThe Docker client honors the HTTP_PROXY , HTTPS_PROXY , and NO_PROXY environment variables (or the\r\nlowercase versions thereof). HTTPS_PROXY takes precedence over HTTP_PROXY .\r\nThe Docker client supports connecting to a remote daemon via SSH:\r\nTo use SSH connection, you need to set up ssh so that it can reach the remote host with public key\r\nauthentication. Password authentication is not supported. If your key is protected with passphrase, you need to set\r\nup ssh-agent .\r\nBind Docker to another host/port or a Unix socket\r\nChanging the default docker daemon binding to a TCP port or Unix docker user group introduces\r\nsecurity risks, as it may allow non-root users to gain root access on the host. Make sure you control\r\naccess to docker . If you are binding to a TCP port, anyone with access to that port has full Docker\r\naccess; so it's not advisable on an open network.\r\nWith -H it's possible to make the Docker daemon to listen on a specific IP and port. By default, it listens on\r\nunix:///var/run/docker.sock to allow only local connections by the root user. You could set it to\r\n0.0.0.0:2375 or a specific host IP to give access to everybody, but that isn't recommended because someone\r\ncould gain root access to the host where the daemon is running.\r\nSimilarly, the Docker client can use -H to connect to a custom port. The Docker client defaults to connecting to\r\nunix:///var/run/docker.sock on Linux, and tcp://127.0.0.1:2376 on Windows.\r\n-H accepts host and port assignment in the following format:\r\nFor example:\r\ntcp:// -\u003e TCP connection to 127.0.0.1 on either port 2376 when TLS encryption is on, or port\r\n2375 when communication is in plain text.\r\ntcp://host:2375 -\u003e TCP connection on host:2375\r\ntcp://host:2375/path -\u003e TCP connection on host:2375 and prepend path to all requests\r\nunix://path/to/socket -\u003e Unix socket located at path/to/socket\r\n-H , when empty, defaults to the same value as when no -H was passed in.\r\n-H also accepts short form for TCP bindings: host: or host:port or :port\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 3 of 16\n\nRun Docker in daemon mode:\r\nDownload an ubuntu image:\r\nYou can use multiple -H , for example, if you want to listen on both TCP and a Unix socket\r\nDaemon storage-driver\r\nOn Linux, the Docker daemon has support for several different image layer storage drivers: overlay2 , fuse-overlayfs , btrfs , and zfs .\r\noverlay2 is the preferred storage driver for all currently supported Linux distributions, and is selected by\r\ndefault. Unless users have a strong reason to prefer another storage driver, overlay2 should be used.\r\nYou can find out more about storage drivers and how to select one in Select a storage driver.\r\nOn Windows, the Docker daemon only supports the windowsfilter storage driver.\r\nOptions per storage driver\r\nParticular storage-driver can be configured with options specified with --storage-opt flags. Options for zfs\r\nstart with zfs , and options for btrfs start with btrfs .\r\nZFS options\r\nzfs.fsname\r\nSpecifies the ZFS filesystem that the daemon should use to create its datasets. By default, the ZFS filesystem in\r\n/var/lib/docker is used.\r\nExample\r\nBtrfs options\r\nbtrfs.min_space\r\nSpecifies the minimum size to use when creating the subvolume which is used for containers. If user uses disk\r\nquota for btrfs when creating or running a container with --storage-opt size option, Docker should ensure the size\r\ncan't be smaller than btrfs.min_space.\r\nExample\r\nOverlay2 options\r\noverlay2.size\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 4 of 16\n\nSets the default max size of the container. It is supported only when the backing filesystem is xfs and mounted\r\nwith pquota mount option. Under these conditions the user can pass any size less than the backing filesystem\r\nsize.\r\nExample\r\nWindowsfilter options\r\nsize\r\nSpecifies the size to use when creating the sandbox which is used for containers. Defaults to 20G.\r\nExample\r\nRuntime options\r\nThe Docker daemon relies on a OCI compliant runtime (invoked via the containerd daemon) as its interface to\r\nthe Linux kernel namespaces , cgroups , and SELinux .\r\nConfigure container runtimes\r\nBy default, the Docker daemon uses runc as a container runtime. You can configure the daemon to add additional\r\nruntimes.\r\ncontainerd shims installed on PATH can be used directly, without the need to edit the daemon's configuration. For\r\nexample, if you install the Kata Containers shim ( containerd-shim-kata-v2 ) on PATH , then you can select that\r\nruntime with docker run without having to edit the daemon's configuration:\r\nContainer runtimes that don't implement containerd shims, or containerd shims installed outside of PATH , must\r\nbe registered with the daemon, either via the configuration file or using the --add-runtime command line flag.\r\nFor examples on how to use other container runtimes, see Alternative container runtimes\r\nConfigure runtimes using daemon.json\r\nTo register and configure container runtimes using the daemon's configuration file, add the runtimes as entries\r\nunder runtimes :\r\nThe key of the entry ( \u003cruntime\u003e in the previous example) represents the name of the runtime. This is the name\r\nthat you reference when you run a container, using docker run --runtime \u003cruntime\u003e .\r\nThe runtime entry contains an object specifying the configuration for your runtime. The properties of the object\r\ndepends on what kind of runtime you're looking to register:\r\nIf the runtime implements its own containerd shim, the object shall contain a runtimeType field and an\r\noptional options field.\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 5 of 16\n\nSee Configure shims.\r\nIf the runtime is designed to be a drop-in replacement for runc, the object contains a path field, and an\r\noptional runtimeArgs field.\r\nSee Configure runc drop-in replacements.\r\nAfter changing the runtimes configuration in the configuration file, you must reload or restart the daemon for\r\nchanges to take effect:\r\nConfigure containerd shims\r\nIf the runtime that you want to register implements a containerd shim, or if you want to register a runtime which\r\nuses the runc shim, use the following format for the runtime entry:\r\nruntimeType refers to either:\r\nA fully qualified name of a containerd shim.\r\nThe fully qualified name of a shim is the same as the runtime_type used to register the runtime in\r\ncontainerd's CRI configuration. For example, io.containerd.runsc.v1 .\r\nThe path of a containerd shim binary.\r\nThis option is useful if you installed the containerd shim binary outside of PATH .\r\noptions is optional. It lets you specify the runtime configuration that you want to use for the shim. The\r\nconfiguration parameters that you can specify in options depends on the runtime you're registering. For most\r\nshims, the supported configuration options are TypeUrl and ConfigPath . For example:\r\nYou can configure multiple runtimes using the same runtimeType. For example:\r\nThe options field takes a special set of configuration parameters when used with \"runtimeType\":\r\n\"io.containerd.runc.v2\" . For more information about runc parameters, refer to the runc configuration section in\r\nCRI Plugin Config Guide.\r\nConfigure runc drop-in replacements\r\nIf the runtime that you want to register can act as a drop-in replacement for runc, you can register the runtime\r\neither using the daemon configuration file, or using the --add-runtime flag for the dockerd cli.\r\nWhen you use the configuration file, the entry uses the following format:\r\nWhere path is either the absolute path to the runtime executable, or the name of an executable installed on\r\nPATH :\r\nAnd runtimeArgs lets you optionally pass additional arguments to the runtime. Entries with this format use the\r\ncontainerd runc shim to invoke a custom runtime binary.\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 6 of 16\n\nWhen you use the --add-runtime CLI flag, use the following format:\r\nDefining runtime arguments via the command line is not supported.\r\nFor an example configuration for a runc drop-in replacement, see Alternative container runtimes \u003e youki\r\nConfigure the default container runtime\r\nYou can specify either the name of a fully qualified containerd runtime shim, or the name of a registered runtime.\r\nYou can specify the default runtime either using the daemon configuration file, or using the --default-runtime\r\nflag for the dockerd cli.\r\nWhen you use the configuration file, the entry uses the following format:\r\nWhen you use the --default-runtime CLI flag, use the following format:\r\nRun containerd standalone\r\nBy default, the Docker daemon automatically starts containerd . If you want to control containerd startup,\r\nmanually start containerd and pass the path to the containerd socket using the --containerd flag. For\r\nexample:\r\nConfigure cgroup driver\r\nYou can configure how the runtime should manage container cgroups, using the --exec-opt\r\nnative.cgroupdriver CLI flag.\r\nYou can only specify cgroupfs or systemd . If you specify systemd and it is not available, the system errors\r\nout. If you omit the native.cgroupdriver option, cgroupfs is used on cgroup v1 hosts, systemd is used on\r\ncgroup v2 hosts with systemd available.\r\nThis example sets the cgroupdriver to systemd :\r\nSetting this option applies to all containers the daemon launches.\r\nConfigure container isolation technology (Windows)\r\nFor Windows containers, you can specify the default container isolation technology to use, using the --exec-opt\r\nisolation flag.\r\nThe following example makes hyperv the default isolation technology:\r\nIf no isolation value is specified on daemon start, on Windows client, the default is hyperv , and on Windows\r\nserver, the default is process .\r\nDaemon DNS options\r\nTo set the DNS server for all Docker containers, use:\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 7 of 16\n\nTo set the DNS search domain for all Docker containers, use:\r\nInsecure registries\r\nIn this section, \"registry\" refers to a private registry, and myregistry:5000 is a placeholder example of a private\r\nregistry.\r\nDocker considers a private registry either secure or insecure. A secure registry uses TLS and a copy of its CA\r\ncertificate is placed on the Docker host at /etc/docker/certs.d/myregistry:5000/ca.crt . An insecure registry\r\nis either not using TLS (i.e., listening on plain text HTTP), or is using TLS with a CA certificate not known by the\r\nDocker daemon. The latter can happen when the certificate wasn't found under\r\n/etc/docker/certs.d/myregistry:5000/ , or if the certificate verification failed (i.e., wrong CA).\r\nBy default, Docker assumes all registries to be secure, except for local registries. Communicating with an insecure\r\nregistry isn't possible if Docker assumes that registry is secure. In order to communicate with an insecure registry,\r\nthe Docker daemon requires --insecure-registry in one of the following two forms:\r\n--insecure-registry myregistry:5000 tells the Docker daemon that myregistry:5000 should be\r\nconsidered insecure.\r\n--insecure-registry 10.1.0.0/16 tells the Docker daemon that all registries whose domain resolve to\r\nan IP address is part of the subnet described by the CIDR syntax, should be considered insecure.\r\nThe flag can be used multiple times to allow multiple registries to be marked as insecure.\r\nIf an insecure registry isn't marked as insecure, docker pull , docker push , and docker search result in error\r\nmessages, prompting the user to either secure or pass the --insecure-registry flag to the Docker daemon as\r\ndescribed above.\r\nLocal registries, whose IP address falls in the 127.0.0.0/8 range, are automatically marked as insecure as of\r\nDocker 1.3.2. It isn't recommended to rely on this, as it may change in the future.\r\nEnabling --insecure-registry , i.e., allowing un-encrypted and/or untrusted communication, can be useful\r\nwhen running a local registry. However, because its use creates security vulnerabilities it should only be enabled\r\nfor testing purposes. For increased security, users should add their CA to their system's list of trusted CAs instead\r\nof enabling --insecure-registry .\r\nLegacy Registries\r\nOperations against registries supporting only the legacy v1 protocol are no longer supported. Specifically, the\r\ndaemon doesn't attempt to push, pull or sign in to v1 registries. The exception to this is search which can still be\r\nperformed on v1 registries.\r\nRunning a Docker daemon behind an HTTPS_PROXY\r\nWhen running inside a LAN that uses an HTTPS proxy, the proxy's certificates replace Docker Hub's certificates.\r\nThese certificates must be added to your Docker host's configuration:\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 8 of 16\n\n1. Install the ca-certificates package for your distribution\r\n2. Ask your network admin for the proxy's CA certificate and append them to /etc/pki/tls/certs/ca-bundle.crt\r\n3. Then start your Docker daemon with HTTPS_PROXY=http://username:password@proxy:port/ dockerd .\r\nThe username: and password@ are optional - and are only needed if your proxy is set up to require\r\nauthentication.\r\nThis only adds the proxy and authentication to the Docker daemon's requests. To use the proxy when building\r\nimages and running containers, see Configure Docker to use a proxy server\r\nDefault ulimit settings\r\nThe --default-ulimit flag lets you set the default ulimit options to use for all containers. It takes the same\r\noptions as --ulimit for docker run . If these defaults aren't set, ulimit settings are inherited from the Docker\r\ndaemon. Any --ulimit options passed to docker run override the daemon defaults.\r\nBe careful setting nproc with the ulimit flag, as nproc is designed by Linux to set the maximum number of\r\nprocesses available to a user, not to a container. For details, see docker run reference.\r\nAccess authorization\r\nDocker's access authorization can be extended by authorization plugins that your organization can purchase or\r\nbuild themselves. You can install one or more authorization plugins when you start the Docker daemon using the\r\n--authorization-plugin=PLUGIN_ID option.\r\nThe PLUGIN_ID value is either the plugin's name or a path to its specification file. The plugin's implementation\r\ndetermines whether you can specify a name or path. Consult with your Docker administrator to get information\r\nabout the plugins available to you.\r\nOnce a plugin is installed, requests made to the daemon through the command line or Docker's Engine API are\r\nallowed or denied by the plugin. If you have multiple plugins installed, each plugin, in order, must allow the\r\nrequest for it to complete.\r\nFor information about how to create an authorization plugin, refer to the authorization plugin section.\r\nDaemon user namespace options\r\nThe Linux kernel user namespace support provides additional security by enabling a process, and therefore a\r\ncontainer, to have a unique range of user and group IDs which are outside the traditional user and group range\r\nutilized by the host system. One of the most important security improvements is that, by default, container\r\nprocesses running as the root user have expected administrative privileges it expects (with some restrictions)\r\ninside the container, but are effectively mapped to an unprivileged uid on the host.\r\nFor details about how to use this feature, as well as limitations, see Isolate containers with a user namespace.\r\nConfigure host gateway IP\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 9 of 16\n\nThe Docker daemon supports a special host-gateway value for the --add-host flag for the docker run and\r\ndocker build commands. This value resolves to addresses on the host, so that containers can connect to services\r\nrunning on the host.\r\nBy default, host-gateway resolves to the IPv4 address of the default bridge, and its IPv6 address if it has one.\r\nYou can configure this to resolve to a different IP using the --host-gateway-ip flag for the dockerd command\r\nline interface, or the host-gateway-ip key in the daemon configuration file.\r\nTo supply both IPv4 and IPv6 addresses on the command line, use two --host-gateway-ip options.\r\nTo supply addresses in the daemon configuration file, use \"host-gateway-ips\" with a JSON array, as shown\r\nbelow. For compatibility with older versions of the daemon, a single IP address can also be specified as a JSON\r\nstring in option \"host-gateway-ip\" .\r\nConfigure CDI devices\r\nContainer Device Interface (CDI) is a standardized mechanism for container runtimes to create containers which\r\nare able to interact with third party devices.\r\nCDI is currently only supported for Linux containers and is enabled by default since Docker Engine 28.3.0.\r\nThe Docker daemon supports running containers with CDI devices if the requested device specifications are\r\navailable on the filesystem of the daemon.\r\nThe default specification directories are:\r\n/etc/cdi/ for static CDI Specs\r\n/var/run/cdi for generated CDI Specs\r\nSet custom locations\r\nTo set custom locations for CDI specifications, use the cdi-spec-dirs option in the daemon.json configuration\r\nfile, or the --cdi-spec-dir flag for the dockerd CLI:\r\nYou can view the configured CDI specification directories using the docker info command.\r\nDisable CDI devices\r\nThe feature in enabled by default. To disable it, use the cdi options in the daemon.json file:\r\nTo check the status of the CDI devices, run docker info .\r\nDaemon logging format\r\nThe --log-format option or \"log-format\" option in the daemon configuration file lets you set the format for logs\r\nproduced by the daemon. The logging format should only be configured either through the --log-format\r\ncommand line option or through the \"log-format\" field in the configuration file; using both the command-line\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 10 of 16\n\noption and the \"log-format\" field in the configuration file produces an error. If this option is not set, the default is\r\n\"text\".\r\nThe following example configures the daemon through the --log-format command line option to use json\r\nformatted logs;\r\nThe following example shows a daemon.json configuration file with the \"log-format\" set;\r\nMiscellaneous options\r\nIP masquerading uses address translation to allow containers without a public IP to talk to other machines on the\r\ninternet. This may interfere with some network topologies, and can be disabled with --ip-masq=false .\r\nDocker supports soft links for the Docker data directory ( /var/lib/docker ) and for /var/lib/docker/tmp . The\r\nDOCKER_TMPDIR and the data directory can be set like this:\r\nDefault cgroup parent\r\nThe --cgroup-parent option lets you set the default cgroup parent for containers. If this option isn't set, it\r\ndefaults to /docker for the cgroupfs driver, and system.slice for the systemd cgroup driver.\r\nIf the cgroup has a leading forward slash ( / ), the cgroup is created under the root cgroup, otherwise the cgroup\r\nis created under the daemon cgroup.\r\nAssuming the daemon is running in cgroup daemoncgroup , --cgroup-parent=/foobar creates a cgroup in\r\n/sys/fs/cgroup/memory/foobar , whereas using --cgroup-parent=foobar creates the cgroup in\r\n/sys/fs/cgroup/memory/daemoncgroup/foobar\r\nThe systemd cgroup driver has different rules for --cgroup-parent . systemd represents hierarchy by slice and\r\nthe name of the slice encodes the location in the tree. So --cgroup-parent for systemd cgroups should be a slice\r\nname. A name can consist of a dash-separated series of names, which describes the path to the slice from the root\r\nslice. For example, --cgroup-parent=user-a-b.slice means the memory cgroup for the container is created in\r\n/sys/fs/cgroup/memory/user.slice/user-a.slice/user-a-b.slice/docker-\u003cid\u003e.scope .\r\nThis setting can also be set per container, using the --cgroup-parent option on docker create and docker\r\nrun , and takes precedence over the --cgroup-parent option on the daemon.\r\nDaemon metrics\r\nThe --metrics-addr option takes a TCP address to serve the metrics API. This feature is still experimental,\r\ntherefore, the daemon must be running in experimental mode for this feature to work.\r\nTo serve the metrics API on localhost:9323 you would specify --metrics-addr 127.0.0.1:9323 , allowing\r\nyou to make requests on the API at 127.0.0.1:9323/metrics to receive metrics in the prometheus format.\r\nPort 9323 is the default port associated with Docker metrics to avoid collisions with other Prometheus exporters\r\nand services.\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 11 of 16\n\nIf you are running a Prometheus server you can add this address to your scrape configs to have Prometheus collect\r\nmetrics on Docker. For more information, see Collect Docker metrics with Prometheus.\r\nNode generic resources\r\nThe --node-generic-resources option takes a list of key-value pair ( key=value ) that allows you to advertise\r\nuser defined resources in a Swarm cluster.\r\nThe current expected use case is to advertise NVIDIA GPUs so that services requesting NVIDIA-GPU=[0-16] can\r\nland on a node that has enough GPUs for the task to run.\r\nExample of usage:\r\nEnable feature in the daemon (--feature)\r\nThe --feature option lets you enable or disable a feature in the daemon. This option corresponds with the\r\n\"features\" field in the daemon.json configuration file. Features should only be configured either through the --\r\nfeature command line option or through the \"features\" field in the configuration file; using both the command-line option and the \"features\" field in the configuration file produces an error. The feature option can be specified\r\nmultiple times to configure multiple features. The --feature option accepts a name and optional boolean value.\r\nWhen omitting the value, the default is true .\r\nThe following example runs the daemon with the cdi and containerd-snapshotter features enabled. The\r\ncdi option is provided with a value;\r\nThe following example is the equivalent using the daemon.json configuration file;\r\nDaemon configuration file\r\nThe --config-file option allows you to set any configuration option for the daemon in a JSON format. This file\r\nuses the same flag names as keys, except for flags that allow several entries, where it uses the plural of the flag\r\nname, e.g., labels for the label flag.\r\nThe options set in the configuration file must not conflict with options set using flags. The Docker daemon fails to\r\nstart if an option is duplicated between the file and the flags, regardless of their value. This is intentional, and\r\navoids silently ignore changes introduced in configuration reloads. For example, the daemon fails to start if you\r\nset daemon labels in the configuration file and also set daemon labels via the --label flag. Options that are not\r\npresent in the file are ignored when the daemon starts.\r\nThe --validate option allows to validate a configuration file without starting the Docker daemon. A non-zero\r\nexit code is returned for invalid configuration files.\r\nOn Linux\r\nThe default location of the configuration file on Linux is /etc/docker/daemon.json . Use the --config-file\r\nflag to specify a non-default location.\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 12 of 16\n\nThe following is a full example of the allowed configuration options on Linux:\r\nYou can't set options in daemon.json that have already been set on daemon startup as a flag. On\r\nsystems that use systemd to start the Docker daemon, -H is already set, so you can't use the hosts\r\nkey in daemon.json to add listening addresses. See custom Docker daemon options for an example on\r\nhow to configure the daemon using systemd drop-in files.\r\nOn Windows\r\nThe default location of the configuration file on Windows is %programdata%\\docker\\config\\daemon.json . Use\r\nthe --config-file flag to specify a non-default location.\r\nThe following is a full example of the allowed configuration options on Windows:\r\nThe default-runtime option is by default unset, in which case dockerd automatically detects the runtime. This\r\ndetection is based on if the containerd flag is set.\r\nAccepted values:\r\ncom.docker.hcsshim.v1 - This is the built-in runtime that Docker has used since Windows supported was\r\nfirst added and uses the v1 HCS API's in Windows.\r\nio.containerd.runhcs.v1 - This is uses the containerd runhcs shim to run the container and uses the v2\r\nHCS API's in Windows.\r\nFeature options\r\nThe optional field features in daemon.json lets you enable or disable specific daemon features.\r\nThe list of feature options include:\r\ncontainerd-snapshotter : when set to true , the daemon uses containerd snapshotters instead of the\r\nclassic storage drivers for storing image and container data. For more information, see containerd storage.\r\nwindows-dns-proxy : when set to true , the daemon's internal DNS resolver will forward requests to\r\nexternal servers. Without this, most applications running in the container will still be able to use secondary\r\nDNS servers configured in the container itself, but nslookup won't be able to resolve external names. The\r\ncurrent default is false , it will change to true in a future release. This option is only allowed on\r\nWindows.\r\nThe windows-dns-proxy feature flag will be removed in a future release.\r\nConfiguration reload behavior\r\nSome options can be reconfigured when the daemon is running without requiring to restart the process. The\r\ndaemon uses the SIGHUP signal in Linux to reload, and a global event in Windows with the key Global\\docker-daemon-config-$PID . You can modify the options in the configuration file, but the daemon still checks for\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 13 of 16\n\nconflicting settings with the specified CLI flags. The daemon fails to reconfigure itself if there are conflicts, but it\r\nwon't stop execution.\r\nThe list of currently supported options that can be reconfigured is this:\r\nOption Description\r\ndebug Toggles debug mode of the daemon.\r\nlabels Replaces the daemon labels with a new set of labels.\r\nlive-restore Toggles live restore.\r\nmax-concurrent-downloads\r\nConfigures the max concurrent downloads for each pull.\r\nmax-concurrent-uploads\r\nConfigures the max concurrent uploads for each push.\r\nmax-download-attempts\r\nConfigures the max download attempts for each pull.\r\ndefault-runtime Configures the runtime to be used if not is specified at container creation.\r\nruntimes Configures the list of available OCI runtimes that can be used to run containers.\r\nauthorization-plugin Specifies the authorization plugins to use.\r\ninsecure-registries Specifies a list of registries that the daemon should consider insecure.\r\nregistry-mirrors Specifies a list of registry mirrors.\r\nshutdown-timeout\r\nConfigures the daemon's existing configuration timeout with a new timeout for\r\nshutting down all containers.\r\nfeatures Enables or disables specific features.\r\nRun multiple daemons\r\nRunning multiple daemons on a single host is considered experimental. You may encounter unsolved\r\nproblems, and things may not work as expected in some cases.\r\nThis section describes how to run multiple Docker daemons on a single host. To run multiple daemons, you must\r\nconfigure each daemon so that it doesn't conflict with other daemons on the same host. You can set these options\r\neither by providing them as flags, or by using a daemon configuration file.\r\nThe following daemon options must be configured for each daemon:\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 14 of 16\n\nWhen your daemons use different values for these flags, you can run them on the same host without any problems.\r\nIt is important that you understand the meaning of these options and to use them correctly.\r\nThe -b, --bridge= flag is set to docker0 as default bridge network. It is created automatically when\r\nyou install Docker. If you aren't using the default, you must create and configure the bridge manually, or\r\nset it to 'none': --bridge=none\r\n--exec-root is the path where the container state is stored. The default value is /var/run/docker .\r\nSpecify the path for your running daemon here.\r\n--data-root is the path where persisted data such as images, volumes, and cluster state are stored. The\r\ndefault value is /var/lib/docker . To avoid any conflict with other daemons, set this parameter separately\r\nfor each daemon.\r\n-p, --pidfile=/var/run/docker.pid is the path where the process ID of the daemon is stored. Specify\r\nthe path for your PID file here.\r\n--host=[] specifies where the Docker daemon listens for client connections. If unspecified, it defaults to\r\n/var/run/docker.sock .\r\n--iptables=false prevents the Docker daemon from adding iptables rules. If multiple daemons manage\r\niptables rules, they may overwrite rules set by another daemon. Be aware that disabling this option requires\r\nyou to manually add iptables rules to expose container ports. If you prevent Docker from adding iptables\r\nrules, Docker also doesn't add IP masquerading rules, even if you set --ip-masq to true . Without IP\r\nmasquerading rules, Docker containers can't connect to external hosts or the internet when using network\r\nother than default bridge.\r\n--config-file=/etc/docker/daemon.json is the path where configuration file is stored. You can use it\r\ninstead of daemon flags. Specify the path for each daemon.\r\n--tls* Docker daemon supports --tlsverify mode that enforces encrypted and authenticated remote\r\nconnections. The --tls* options enable use of specific certificates for individual daemons.\r\nExample script for a separate “bootstrap” instance of the Docker daemon without network:\r\nDefault network options\r\nThe default-network-opts key in the daemon.json configuration file, and the equivalent --default-network-opt CLI flag, let you specify default values for driver network driver options for new networks.\r\nThe following example shows how to configure options for the bridge driver using the daemon.json file.\r\nThis example uses the bridge network driver. Refer to the bridge network driver page for an overview of\r\navailable driver options.\r\nAfter changing the configuration and restarting the daemon, new networks that you create use these option\r\nconfigurations as defaults.\r\nNote that changing this daemon configuration doesn't affect pre-existing networks.\r\nUsing the --default-network-opt CLI flag is useful for testing and debugging purposes, but you should prefer\r\nusing the daemon.json file for persistent daemon configuration. The CLI flag expects a value with the following\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 15 of 16\n\nformat: driver=opt=value , for example:\r\nSource: https://docs.docker.com/engine/reference/commandline/dockerd/\r\nhttps://docs.docker.com/engine/reference/commandline/dockerd/\r\nPage 16 of 16",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://docs.docker.com/engine/reference/commandline/dockerd/"
	],
	"report_names": [
		"dockerd"
	],
	"threat_actors": [],
	"ts_created_at": 1775446664,
	"ts_updated_at": 1775791324,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/eec77de53538bd545d769b1a7dad39c4b3eb933b.pdf",
		"text": "https://archive.orkl.eu/eec77de53538bd545d769b1a7dad39c4b3eb933b.txt",
		"img": "https://archive.orkl.eu/eec77de53538bd545d769b1a7dad39c4b3eb933b.jpg"
	}
}