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

Not specified by the original author.

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.

2. 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.

3. 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.

Asked: how to fix invalid mount config for type "tmpfs": invalid option: uid. Verified answer: Fixes tmpfs mount failures when uid or gid options are passed through the Mounts API long syntax. Use when container create fails with 'invalid option: uid' on a tmpfs mount. Move the options to the --tmpfs / HostConfig.Tmpfs short syntax instead. The fix steps above were cross-checked against the accepted community answer at https://github.com/crewship-ai/crewship/pull/1070 (gh:crewship-ai/crewship#1070), which confirms the same resolution.

Not specified by the original author.

Platform.sh deploy hooks can only write to configured mounts; the app dir is read-only

TL;DR

On Platform.sh, the deployed filesystem is read-only except for your configured mounts. Any deploy-hook step that writes files (generated config, env-derived secrets, compiled assets not built earlier) must target a writable mount path, or the hook fails with a permission error. Pattern: declare the mount in .platform.app.yaml under mounts (e.g.

Use this when you run into the situation in the title.

When not to use this skill: unrelated tasks. It covers only the procedure above.

Compatibility

The steps above apply to the commands named in them. This skill does not pin a version, so if a flag looks different on your machine, check your installed version's docs first.

Details

a shared files dir), then have the deploy hook write there. If you need environment variables materialized as files, write them during the deploy hook to the mount, never to the app root. Test the write path on a branch environment first: read-only violations only show up at deploy time.

Context: Web source (platformsh-env-files package docs on skypack.dev): when writing files at deploy time on Platform.sh, most directories are read-only by default, so you must choose a writable location (a configured mount). The package writes platform.sh env vars whose names start with file: to the named file, and must run from the build or deploy hook targeting a writable path.

Source: Web source (platformsh-env-files package docs on skypack.dev): when writing files at deploy time on Platform.sh, most directories are read-only by default, so you must choose a writable location (a configured mount). The package writes platform.sh env vars whose names start with file: to the named file, and must run from the build or deploy hook targeting a writable path.

Verified resolution: On Platform.sh, the deployed filesystem is read-only except for your configured mounts. Any deploy-hook step that writes files (generated config, env-derived secrets, compiled assets not built earlier) must target a writable mount path, or the hook fails with a permission error. Pattern: declare the mount in .platform.app.yaml under mounts (e.g. a shared files dir), then have the deploy hook write there. If you need environment variables materialized as files, write them during the deploy hook to the mount, never to the app root. Test the write path on a branch environment first: read-only violations only show up at deploy time.

Source URL: https://www.skypack.dev/view/platformsh-env-files

Not specified by the original author.

TL;DR

Fix it by chowning the host directory to the meili UID before starting the container, or run the container with a user flag matching your host UID.

Steps

1. If your Docker-mounted Meilisearch data directory stays empty, check ownership, not the config. The official image runs as the meili user, so a host directory owned by root is not writable by the container and nothing lands in the volume. Fix it by chowning the host directory to the meili UID before starting the container, or run the container with a user flag matching your host UID. The empty folder with no error message is the classic symptom.

When to use

You are seeing this: If your Docker-mounted Meilisearch data directory stays empty, check ownership, not the config. Use this skill when you run into "Docker volume stays empty - the image runs as the meili user, chown the host dir".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

Versions mentioned in the source: Meilisearch v0.24. If you are on something much newer or older, the details may have shifted.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Source: Issue meilisearch/meilisearch#1969 (closed, 46 comments): running Meilisearch v0.24 in Docker with a mounted volume at the data path wrote nothing - the host folder stayed empty even though the docs said data lands there. The maintainer traced it to the meili user the Docker image runs as: the mounted directory was owned by root on the host, so the process silently could not write.

Verified resolution: If your Docker-mounted Meilisearch data directory stays empty, check ownership, not the config. The official image runs as the meili user, so a host directory owned by root is not writable by the container and nothing lands in the volume. Fix it by chowning the host directory to the meili UID before starting the container, or run the container with a user flag matching your host UID. The empty folder with no error message is the classic symptom.

Source URL: https://github.com/meilisearch/meilisearch/issues/1969