How to fix Error response from daemon: secret not found: mysecret in Docker

DockerBEGINNERMEDIUMUpdated Dec 6, 2025· 88 views

This error occurs when Docker Swarm cannot locate a secret that a service is trying to use. The fix typically involves creating the missing secret, verifying secret names match between your service definition and the secret store, or ensuring you're operating on a Swarm manager node.

Quick fix

Fixes Error response from daemon: secret not found: mysecret

docker secret ls
  1. List existing secrets in the Swarm
  2. Verify you're on a Swarm manager node
  3. Create the missing secret
  4. Verify secret name matches service definition
docker — error
docker secret ls
Error response from daemon: secret not found: mysecret

What this error means

The "secret not found" error in Docker Swarm indicates that the orchestrator cannot locate a secret referenced by your service in the cluster's secret store. Docker Swarm secrets are a secure way to manage sensitive data like passwords, API keys, and certificates that your containers need at runtime. When you deploy a service that references a secret by name, Docker Swarm looks up that secret in its internal encrypted store (managed by the Raft consensus algorithm across manager nodes). If the secret doesn't exist or the name doesn't match exactly, you'll see this error. Unlike environment variables, Swarm secrets are encrypted at rest and in transit, and are only mounted into containers that explicitly need them via an in-memory tmpfs filesystem at `/run/secrets/<secret_name>`. This makes them the recommended way to handle sensitive configuration in production Swarm deployments.

Typical symptoms

  • Service deployment fails with 'secret not found' error
  • docker stack deploy fails when referencing a secret
  • docker service create fails when attaching a secret
  • docker service update --secret-add fails to find the secret
  • Container fails to start due to missing secret mount
  • CI/CD pipeline fails at service deployment stage

Common causes

  1. The secret was never created in the Swarm cluster
  2. Secret name in service definition doesn't match the actual secret name (case-sensitive)
  3. Trying to use a secret ID instead of the secret name
  4. Running the command on a worker node instead of a manager node
  5. Secret was deleted and needs to be recreated
  6. Using docker-compose without Swarm mode initialized
  7. Typo in the secret name in docker-compose.yml or service definition
  8. Secret exists in a different Swarm cluster than the one you're deploying to

How to fix "Error response from daemon: secret not found: mysecret"

1List existing secrets in the Swarm

First, check what secrets currently exist in your Swarm cluster:

bash
docker secret ls

This command must be run on a Swarm manager node. If you see your secret listed, the issue is likely a name mismatch. If it's not listed, you need to create it.

You can also inspect a specific secret to see its metadata (not the value):

bash
docker secret inspect mysecret
2Verify you're on a Swarm manager node

Secret management commands only work on manager nodes. Check your node's role:

bash
docker info | grep "Is Manager"

If you see "Is Manager: false" or get an error about Swarm not being active, you need to either:

1. SSH into a manager node, or
2. Initialize Swarm if it's not running:

bash
docker swarm init
3Create the missing secret

Create the secret using one of these methods:

From a file:

bash
docker secret create mysecret /path/to/secret/file

From stdin (recommended for sensitive data):

bash
echo "my_secret_value" | docker secret create mysecret -

Or using printf to avoid newline issues:

bash
printf "my_secret_value" | docker secret create mysecret -

After creation, verify it exists:

bash
docker secret ls
4Verify secret name matches service definition

Check your docker-compose.yml or service definition to ensure the secret name matches exactly (case-sensitive).

In docker-compose.yml:

yaml
services:
  myapp:
    image: myapp:latest
    secrets:
      - mysecret  # Must match the secret name exactly

secrets:
  mysecret:
    external: true  # References an existing Swarm secret

For external secrets, the name must match what's in docker secret ls. If you're defining the secret in the compose file itself:

yaml
secrets:
  mysecret:
    file: ./my_secret.txt  # Creates secret from file during deploy
5Redeploy the service

After creating or fixing the secret, redeploy your service:

Using docker stack:

bash
docker stack deploy -c docker-compose.yml mystack

Using docker service:

bash
docker service update --secret-add mysecret myservice

Or if recreating the service:

bash
docker service create --name myservice --secret mysecret myimage
6Verify secret is accessible in the container

Once the service is running, verify the secret is mounted correctly:

bash
docker exec -it <container_id> ls -la /run/secrets/
docker exec -it <container_id> cat /run/secrets/mysecret

The secret should be available as a file at /run/secrets/mysecret. Your application should read from this file path, not from an environment variable.

Advanced notes

Secret name vs ID: When using docker service update --secret-add, you must use the secret name, not its ID. Using the ID will result in a "secret not found" error even if the secret exists. This is a common gotcha.

Secrets are immutable: You cannot update an existing secret's value. To change a secret, you must:
1. Create a new secret with a different name
2. Update the service to use the new secret
3. Remove the old secret

bash
docker secret create mysecret_v2 /path/to/new/secret
docker service update --secret-rm mysecret --secret-add mysecret_v2 myservice
docker secret rm mysecret

Using secrets with docker-compose (without Swarm): In non-Swarm mode, docker-compose can still use secrets, but they work differently. The secret file is bind-mounted directly:

yaml
secrets:
  mysecret:
    file: ./secrets/mysecret.txt  # Local file path

_FILE environment variables: Many official Docker images support the _FILE suffix pattern. Instead of:

yaml
environment:
  - MYSQL_PASSWORD=/run/secrets/db_password  # WRONG - this is a string

Use:

yaml
environment:
  - MYSQL_ROOT_PASSWORD_FILE=/run/secrets/db_password  # CORRECT

Secret rotation in production: For zero-downtime secret rotation:
1. Create the new secret
2. Update the service with both old and new secrets
3. Update application to use new secret
4. Remove old secret from service
5. Delete old secret from Swarm

Debugging secret issues:

bash
# Check service logs
docker service logs myservice

# Inspect service to see attached secrets
docker service inspect myservice --pretty | grep -A 10 Secrets

# Check if container is receiving the secret
docker inspect <container_id> | jq '.[0].Mounts[] | select(.Type=="tmpfs")'

Frequently asked questions

What does "Error response from daemon: secret not found: mysecret" mean?
The "secret not found" error in Docker Swarm indicates that the orchestrator cannot locate a secret referenced by your service in the cluster's secret store. Docker Swarm secrets are a secure way to manage sensitive data like passwords, API keys, and certificates that your containers need at runtime. When you deploy a service that references a secret by name, Docker Swarm looks up that secret in its internal encrypted store (managed by the Raft consensus algorithm across manager nodes).
How do I fix "Error response from daemon: secret not found: mysecret"?
This error occurs when Docker Swarm cannot locate a secret that a service is trying to use. The fix typically involves creating the missing secret, verifying secret names match between your service definition and the secret store, or ensuring you're operating on a Swarm manager node.
What causes "Error response from daemon: secret not found: mysecret"?
The secret was never created in the Swarm cluster Secret name in service definition doesn't match the actual secret name (case-sensitive) Trying to use a secret ID instead of the secret name
Is the "Error response from daemon: secret not found: mysecret" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading