How to fix Error response from daemon: failed to initialize logging driver in Docker

DockerINTERMEDIATEHIGHUpdated Dec 6, 2025ยท 316 views

This error occurs when Docker cannot initialize the specified logging driver for a container. Common causes include misconfigured driver options, unavailable logging backends (journald, syslog, cloud services), missing credentials, or network connectivity issues to remote logging endpoints.

Quick fix

Fixes Error response from daemon: failed to initialize logging driver

failed to initialize logging driver: journald is not enabled on this host
failed to initialize logging driver: Unix syslog delivery error
failed to initialize logging driver: database is locked
failed to initialize logging driver: unable to connect or authenticate with Google Cloud Logging
failed to initialize logging driver: NoCredentialProviders: no valid providers in chain
  1. Identify the specific logging driver and error
  2. Fall back to default json-file driver
  3. Fix journald driver issues
  4. Fix syslog driver issues
docker โ€” error
failed to initialize logging driver: journald is not enabled on this host
failed to initialize logging driver: Unix syslog delivery error
failed to initialize logging driver: database is locked
failed to initialize logging driver: unable to connect or authenticate with Google Cloud Logging
failed to initialize logging driver: NoCredentialProviders: no valid providers in chain
Error response from daemon: failed to initialize logging driver

What this error means

When you start a container, Docker initializes a logging driver to capture and forward container logs. The logging driver is specified either in the container's run command, docker-compose.yml, or in the daemon's default configuration (/etc/docker/daemon.json). The "failed to initialize logging driver" error indicates that Docker attempted to set up the logging driver but encountered a problem that prevents it from functioning. This can happen for several reasons: - **Driver not available**: The specified logging driver (journald, syslog, gelf, fluentd, awslogs, gcplogs, splunk, etc.) is not supported on the current platform or Docker version - **Backend unavailable**: The logging backend service (syslog daemon, journald, Loki, Splunk HEC, CloudWatch) is not running or accessible - **Authentication failure**: Cloud-based logging drivers (awslogs, gcplogs, splunk) cannot authenticate with the remote service - **Configuration errors**: Invalid log-opts parameters, wrong URLs, or malformed credentials - **Network issues**: Cannot connect to remote logging endpoints due to firewall rules, DNS resolution, or network timeouts - **Database locked**: On Synology NAS systems, the logging database can become locked This is a critical error because the container will not start until the logging driver can be successfully initialized.

Typical symptoms

  • Container fails to start with 'Error response from daemon: failed to initialize logging driver'
  • Error message includes specific driver name: journald, syslog, awslogs, gcplogs, splunk, loki, fluentd, gelf
  • Error mentions 'Unix syslog delivery error' when using syslog driver
  • Error mentions 'database is locked' on Synology NAS systems
  • Error mentions 'unable to connect or authenticate' for cloud logging drivers
  • Error mentions 'NoCredentialProviders' when using AWS CloudWatch logs
  • Docker Compose services fail to start with logging configuration
  • Container works with default json-file driver but fails with custom driver

Common causes

  1. Logging driver specified is not supported on the current platform (e.g., journald on Windows)
  2. Syslog daemon is not running on the host when using syslog driver
  3. Missing or invalid AWS credentials when using awslogs driver
  4. Missing or invalid Google Cloud credentials when using gcplogs driver
  5. Splunk HTTP Event Collector (HEC) endpoint is unreachable or token is invalid
  6. Loki endpoint URL is incorrect or Loki service is not running
  7. Fluentd service is not running or configured incorrectly
  8. Database lock on Synology NAS Docker installations
  9. Incorrect log-opts syntax in docker-compose.yml or daemon.json
  10. Network firewall blocking connection to remote logging service
  11. DNS resolution failure for remote logging endpoint
  12. TLS certificate errors when connecting to secure logging endpoints

How to fix "Error response from daemon: failed to initialize logging driver"

1Identify the specific logging driver and error

First, determine which logging driver is failing and the exact error message:

Check the full error message:

The error typically includes the driver name and a more specific reason:

bash
failed to initialize logging driver: journald is not enabled on this host
failed to initialize logging driver: Unix syslog delivery error
failed to initialize logging driver: database is locked
failed to initialize logging driver: unable to connect or authenticate with Google Cloud Logging
failed to initialize logging driver: NoCredentialProviders: no valid providers in chain

Check your container's logging configuration:

bash
# For a specific container
docker inspect <container_name> | grep -A 10 "LogConfig"

# Check daemon default logging driver
docker info | grep "Logging Driver"

Check docker-compose.yml if using Compose:

Look for the logging section in your service configuration:

yaml
services:
  myapp:
    image: myapp:latest
    logging:
      driver: syslog  # <-- This is the driver causing issues
      options:
        syslog-address: "tcp://localhost:514"
2Fall back to default json-file driver

The quickest way to get your container running is to use the default json-file driver:

Override at runtime:

bash
docker run --log-driver=json-file myimage

Override in docker-compose.yml:

yaml
services:
  myapp:
    image: myapp:latest
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Override in daemon.json:

Edit /etc/docker/daemon.json:

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

Then restart Docker:

bash
sudo systemctl restart docker

Note: This is a temporary workaround. Continue with the following steps to fix the actual driver issue.

3Fix journald driver issues

The journald driver is only available on Linux systems with systemd.

Error:

bash
failed to initialize logging driver: journald is not enabled on this host

Check if journald is available:

bash
# Check if systemd-journald is running
systemctl status systemd-journald

# Check if journald logging is enabled
cat /etc/systemd/journald.conf | grep Storage

On systems without journald (Docker Desktop for Windows/macOS):

Switch to a different driver. journald is not available on Windows or macOS Docker Desktop.

bash
docker run --log-driver=json-file myimage
# or
docker run --log-driver=local myimage

If journald is installed but not working:

bash
# Ensure journald is running
sudo systemctl enable systemd-journald
sudo systemctl start systemd-journald

# Restart Docker
sudo systemctl restart docker
4Fix syslog driver issues

The syslog driver requires a syslog daemon running on the host or a reachable remote syslog server.

Error:

bash
failed to initialize logging driver: Unix syslog delivery error

Check if syslog is running locally:

bash
# Check rsyslog status
sudo systemctl status rsyslog

# Or check syslog-ng
sudo systemctl status syslog-ng

# Verify syslog socket exists
ls -la /dev/log

Start syslog if not running:

bash
sudo systemctl enable rsyslog
sudo systemctl start rsyslog

For remote syslog, verify the address format:

yaml
# docker-compose.yml
logging:
  driver: syslog
  options:
    syslog-address: "tcp://192.168.1.100:514"  # Use tcp:// or udp://
    syslog-facility: daemon
    tag: "{{.Name}}"

Common mistake - wrong option name:

yaml
# WRONG
options:
  address: "tcp://localhost:514"

# CORRECT
options:
  syslog-address: "tcp://localhost:514"
5Fix AWS CloudWatch (awslogs) driver issues

The awslogs driver requires valid AWS credentials with CloudWatch Logs permissions.

Error:

bash
failed to initialize logging driver: NoCredentialProviders: no valid providers in chain

Option 1: Use IAM Instance Role (EC2):

Ensure your EC2 instance has an IAM role with CloudWatch Logs permissions:

json
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogGroup",
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "*"
    }
  ]
}

Option 2: Use environment variables:

bash
export AWS_ACCESS_KEY_ID=your_access_key
export AWS_SECRET_ACCESS_KEY=your_secret_key
export AWS_REGION=us-east-1

docker run --log-driver=awslogs \
  --log-opt awslogs-region=us-east-1 \
  --log-opt awslogs-group=my-log-group \
  --log-opt awslogs-stream=my-container \
  myimage

Option 3: Use AWS credentials file:

Create ~/.aws/credentials:

ini
[default]
aws_access_key_id = your_access_key
aws_secret_access_key = your_secret_key

Verify AWS connectivity:

bash
aws logs describe-log-groups --region us-east-1
6Fix Google Cloud (gcplogs) driver issues

The gcplogs driver requires valid Google Cloud credentials and appropriate IAM permissions.

Error:

bash
failed to initialize logging driver: unable to connect or authenticate with Google Cloud Logging

Option 1: Use GCE VM Service Account (recommended on GCE):

Ensure your VM has the "Cloud Logging Write" scope enabled:

bash
# Check VM scopes
gcloud compute instances describe INSTANCE_NAME --format="get(serviceAccounts)"

Option 2: Use Application Default Credentials:

bash
# Authenticate locally
gcloud auth application-default login

# Set the project
export GOOGLE_CLOUD_PROJECT=your-project-id

Option 3: Use a service account key:

bash
export GOOGLE_APPLICATION_CREDENTIALS=/path/to/service-account-key.json

docker run --log-driver=gcplogs \
  --log-opt gcp-project=your-project-id \
  myimage

Verify Google Cloud connectivity:

bash
gcloud logging write test-log "Test message"

Note: Sometimes simply restarting the server resolves transient authentication issues with gcplogs.

7Fix Splunk driver issues

The Splunk driver sends logs to Splunk HTTP Event Collector (HEC).

Common issues:

1. HEC endpoint unreachable
2. Invalid HEC token
3. TLS certificate errors

Test HEC connectivity first:

bash
curl -k https://splunk.example.com:8088/services/collector/health

Test with a simple event:

bash
curl -k https://splunk.example.com:8088/services/collector \
  -H "Authorization: Splunk YOUR_HEC_TOKEN" \
  -d '{"event": "test"}'

Correct Splunk driver configuration:

bash
docker run --log-driver=splunk \
  --log-opt splunk-token=YOUR_HEC_TOKEN \
  --log-opt splunk-url=https://splunk.example.com:8088 \
  --log-opt splunk-insecureskipverify=true \
  myimage

In docker-compose.yml:

yaml
logging:
  driver: splunk
  options:
    splunk-token: "YOUR_HEC_TOKEN"
    splunk-url: "https://splunk.example.com:8088"
    splunk-verify-connection: "false"
    splunk-insecureskipverify: "true"  # For self-signed certs

Note: All log-opts values must be strings (enclosed in quotes).

8Fix Loki driver issues

The Loki driver (Docker plugin) sends logs to Grafana Loki.

Error:

bash
Cannot start service: failed to initialize logging driver: error creating loki logger

Install the Loki Docker plugin:

bash
docker plugin install grafana/loki-docker-driver:latest --alias loki --grant-all-permissions

Verify plugin is installed and enabled:

bash
docker plugin ls

Check Loki is accessible:

bash
curl http://loki.example.com:3100/ready

Correct Loki configuration:

yaml
# docker-compose.yml
logging:
  driver: loki
  options:
    loki-url: "http://loki.example.com:3100/loki/api/v1/push"
    loki-batch-size: "400"
    loki-retries: "3"

If using authentication:

yaml
options:
  loki-url: "http://loki.example.com:3100/loki/api/v1/push"
  loki-external-labels: "job=docker,container={{.Name}}"
  loki-tenant-id: "tenant1"

Common issue - Loki URL format:

yaml
# WRONG - missing /loki/api/v1/push
loki-url: "http://loki:3100"

# CORRECT
loki-url: "http://loki:3100/loki/api/v1/push"
9Fix Synology NAS 'database is locked' error

On Synology NAS systems, Docker can encounter a locked logging database.

Error:

bash
failed to initialize logging driver: database is locked

Solution 1: Duplicate the container settings:

1. Open Docker app in Synology DSM
2. Stop the problematic container
3. Right-click on the container -> Settings -> Duplicate Settings
4. This creates a new container with the same settings
5. Delete the old container and use the new one

Note: Local port mappings will be set to "Auto" and need to be reconfigured manually.

Solution 2: Restart Docker package:

1. Open Package Center in DSM
2. Find Docker and click Stop
3. Wait 30 seconds
4. Click Start

Solution 3: SSH and clear the lock:

bash
sudo synoservice --restart pkgctl-Docker

Root cause: The logging database for the specific container has been locked by another process, possibly due to an improper shutdown or resource contention.

10Verify log-opts syntax in configuration files

Incorrect log-opts syntax is a common cause of initialization failures.

Important: All log-opts values in daemon.json must be strings:

json
// WRONG - numeric and boolean values
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": 10m,
    "max-file": 3,
    "compress": true
  }
}

// CORRECT - all values as strings
{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3",
    "compress": "true"
  }
}

In docker-compose.yml:

yaml
# Ensure all options are quoted strings
logging:
  driver: json-file
  options:
    max-size: "10m"     # String
    max-file: "3"       # String, not integer
    compress: "true"    # String, not boolean

Validate daemon.json:

bash
cat /etc/docker/daemon.json | jq .

Restart Docker after configuration changes:

bash
sudo systemctl daemon-reload
sudo systemctl restart docker

Advanced notes

### Supported Logging Drivers by Platform

Not all logging drivers are available on all platforms:

| Driver | Linux | Windows | macOS (Desktop) |
|--------|-------|---------|-----------------|
| json-file | Yes | Yes | Yes |
| local | Yes | Yes | Yes |
| syslog | Yes | No | No |
| journald | Yes (systemd) | No | No |
| gelf | Yes | Yes | Yes |
| fluentd | Yes | Yes | Yes |
| awslogs | Yes | Yes | Yes |
| splunk | Yes | Yes | Yes |
| gcplogs | Yes | Yes | Yes |

### Dual Logging for docker logs Support

Some logging drivers (syslog, journald, gelf, fluentd, awslogs, splunk, gcplogs) don't support the docker logs command by default. Docker 20.10+ supports "dual logging" which sends logs to both the driver and a local cache:

json
{
  "log-driver": "splunk",
  "log-opts": {
    "splunk-token": "YOUR_TOKEN",
    "splunk-url": "https://splunk:8088",
    "cache-disabled": "false",
    "cache-max-size": "100m"
  }
}

### Non-Blocking Mode for High-Throughput Containers

For containers that generate logs faster than the driver can process them, enable non-blocking mode:

json
{
  "log-driver": "syslog",
  "log-opts": {
    "mode": "non-blocking",
    "max-buffer-size": "4m"
  }
}

Warning: In non-blocking mode, logs may be dropped if the buffer fills up.

### Troubleshooting Remote Logging Connectivity

Test network connectivity:

bash
# TCP connection test
nc -zv logging.example.com 514

# DNS resolution
nslookup logging.example.com

# Curl test (for HTTP-based drivers)
curl -v https://logging.example.com:8088/health

Check firewall rules:

bash
# iptables
sudo iptables -L -n | grep 514

# firewalld
sudo firewall-cmd --list-all

### Using the local Driver as an Alternative

The local driver is a good alternative to json-file with automatic log rotation:

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

Benefits:
- Built-in log rotation (unlike json-file default)
- More efficient binary format
- Supports docker logs command
- No external dependencies

### Kubernetes/Docker Swarm Considerations

In orchestrated environments, logging driver failures can cause:
- Pods/tasks stuck in "ContainerCreating" state
- Service deployments timing out
- Rolling updates failing

Always test logging driver configuration on a single node before deploying cluster-wide.

Frequently asked questions

What does "Error response from daemon: failed to initialize logging driver" mean?
When you start a container, Docker initializes a logging driver to capture and forward container logs. json). The "failed to initialize logging driver" error indicates that Docker attempted to set up the logging driver but encountered a problem that prevents it from functioning.
How do I fix "Error response from daemon: failed to initialize logging driver"?
This error occurs when Docker cannot initialize the specified logging driver for a container. Common causes include misconfigured driver options, unavailable logging backends (journald, syslog, cloud services), missing credentials, or network connectivity issues to remote logging endpoints.
What causes "Error response from daemon: failed to initialize logging driver"?
Logging driver specified is not supported on the current platform (e.g., journald on Windows) Syslog daemon is not running on the host when using syslog driver Missing or invalid AWS credentials when using awslogs driver
Is the "Error response from daemon: failed to initialize logging driver" error serious?
Yes. This is a high-severity error that usually blocks work until it is fixed, but the steps above resolve it.

Official resources & further reading