invalid mount config for type "tmpfs": invalid option: uid

TL;DR: Move uid/gid off the long syntax. Use --tmpfs /secrets:uid=1001,gid=1001,mode=0700 (or the HostConfig.Tmpfs API field) instead of --mount type=tmpfs with uid/gid options. The daemon only implements uid/gid for tmpfs on the legacy short-syntax path; the Mounts API rejects them as invalid options.

The error

invalid mount config for type "tmpfs": invalid option: uid

Fix it

1. Switch to the short syntax (CLI):

docker run --tmpfs /secrets:uid=1001,gid=1001,mode=0700,size=16m [image] Expected: container starts; mount | grep /secrets shows uid=1001,gid=1001.

1. In the Engine API or a Docker SDK, put the entry in HostConfig.Tmpfs instead of Mounts:

{"HostConfig": {"Tmpfs": {"/secrets": "uid=1001,gid=1001,mode=0700,size=16m"}}} Expected: create returns 201 instead of the mount-config error.

1. In compose, use the short list form:

tmpfs: - /secrets:uid=1001,gid=1001,mode=0700 Expected: docker compose up starts the service.

When this applies

• Container create through the Engine API/SDK with mount.Mount{Type: tmpfs, TmpfsOptions.Options: [[uid,...],[gid,...]]}
• --mount type=tmpfs long syntax carrying uid/gid

When this does NOT apply

• Plain --tmpfs /path with no options (always works)
• tmpfs-size / tmpfs-mode in the long syntax (those are valid there)
• tmpfs filling up at runtime ("no space left" is a different problem)

Versions

Docker Engine 20.10 through 29.x (reproduced on 29.3.0).

Why it happens

The daemon implements uid/gid/mode/size for tmpfs only through the legacy HostConfig.Tmpfs option-string path. The newer Mounts API TmpfsOptions accepts a smaller option set, so uid/gid passed that way are rejected during mount validation, before the container is created.

Edge cases

• mode works in both syntaxes; only uid/gid are rejected via the Mounts API.
• Short-syntax size accepts m/g suffixes (size=16m); long-syntax tmpfs-size wants raw bytes.
• tmpfs is RAM-backed and non-persistent; do not put data you need after restart there.