Repository navigation
[BUG] mode attribute in configs works but raises an unsupported warning #14288
Description
Description
The latest version of compose raises the following warning when the mode attribute is provided under configs, even though it works as expected:
WARN[0000] service "test": configs.start.sh.mode: mode is not supported outside Swarm mode and will be ignored
- With mode:
test-1 | -rwx------ 1 root root 52 Oct 6 11:52 /start.sh
- Without mode:
test-1 | -r--r--r-- 1 root root 52 Oct 6 11:54 /start.sh
PoC:
services:
test:
image: alpine
command: sh /start.sh
configs:
- source: start.sh
target: /start.sh
mode: 0700
configs:
start.sh:
content: |
#!/usr/bin/env sh
ls -l /start.sh
tail -f /dev/null
Steps To Reproduce
- Create a compose file with the
configssection andmode - Start the container:
docker compose up - Observe the file permissions and the logged warning
Compose Version
Docker Compose version v5.6.0
Docker Environment
Client: Docker Engine - Community
Version: 29.8.2
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.37.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v5.6.0
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 13
Running: 13
Paused: 0
Stopped: 0
Images: 61
Server Version: 29.8.2
Storage Driver: overlayfs
driver-type: io.containerd.snapshotter.v1
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: ee2735368117d2eb259779949d5e75cdafec9761
runc version: v1.5.1-0-g8f2685a4
init version: de40ad0
Security Options:
apparmor
Profile: default
seccomp
Profile: builtin
cgroupns
Kernel Version: 7.0.0-38-generic
Operating System: Linux Mint 22.3
OSType: linux
Architecture: x86_64
CPUs: 22
Total Memory: 30.85GiB
Name: xxx
ID: xx-xxx-xxx-xxx-xxx
Docker Root Dir: /var/lib/docker
Debug Mode: false
Username: xxxx
Experimental: false
Insecure Registries:
127.0.0.0/8
::1/128
Live Restore Enabled: false
Default Address Pools:
Base: 172.16.0.0/12, Size: 24
Firewall Backend: iptables
EnableUserlandProxy: true
UserlandProxyPath: /usr/bin/docker-proxy
Anything else?
No response
Reacted by LE and peterhirn
Activity
[-][BUG] `configs` block mode working but raises a warning[/-][+][BUG] `mode` attribute in `configs` works but raises an unsupported warning[/+]NisargJasani0602 commentedon Oct 6, 2026
I looked into this and found the cause.
Cause
The warning comes from
fileReferenceReportinpkg/compose/unsupported_attributes.go. It flagsuid,gidandmodeon every service-levelconfigs:/secrets:reference as "not supported outside Swarm mode", whatever the source of the config or secret is.That is only true for some of them. Compose handles them in two ways:
content:andenvironment:sources are copied into the container as a tar entry (createTarinpkg/compose/secrets.go), which sets the file mode, uid and gid. So these are honored, as the reporter observed.file:sources are bind-mounted read-only (buildContainerConfigMountsinpkg/compose/create.go).mode,uidandgidreally are ignored there, so the warning is correct for them.Reproduction
I built v5.6.0 (the version in this report) and ran
docker compose up -dwithmode: 0700,uid: "1234"andgid: "5678"on each reference:configswithcontent:-rwx------ 1234 5678(applied)configswithenvironment:-rwx------ 1234 5678(applied)configswithfile:-rw-r--r-- 0 0(ignored)secretswithenvironment:-rwx------ 1234 5678(applied)secretswithfile:-rw-r--r-- 0 0(ignored)So the warning fires for every source, but it's only accurate for
file:.secrets:have nocontent:source in the schema, so that case doesn't exist for them. I ran this on macOS with Docker Desktop (engine 28.3.2), not on Linux as in the report. The code involved is identical between v5.6.0 and currentmain.Why it isn't a one-line fix
The check (
hasFileReferenceOverride) only sees the service's reference to a config, not the top-levelconfigs:/secrets:definition wherecontent:/environment:/file:is declared. Fixing it means making that information available to the check, for example by filtering the findings once the project is loaded. The tests that assert the current behaviour (pkg/compose/unsupported_attributes_test.goand the e2e scenario inpkg/e2e/unsupported_attributes_test.go) would need updating.I'm happy to work on a fix if a maintainer is fine with this direction.
ndeloof commentedon Oct 7, 2026
@NisargJasani0602 the root cause indeed is that mode / uid / gid are actually supported for secrets/config set by env var on inlined. The restriction is only relevant for file-based resources. Feel free to propose a fix
ndeloof commentedon Oct 7, 2026
also see #14283
NisargJasani0602 commentedon Oct 7, 2026
I have a fix for this ready, and I plan to open a PR for it. It will also close #14283, which has the same root cause (the
uid/gidwarning on inline configs).Approach
The warning is only accurate for
file:sources, which are bind-mounted, souid/gid/modereally are ignored there. Forcontent:andenvironment:sources they are applied. The check can't tell the two apart, because it only sees the service's reference to a config, not the top-level definition. So I filter the findings once the project is loaded, dropping the ones whose source is inline.file:references keep their warning.I checked it with a real build:
file:sources still warn.I also added unit tests for inline, environment and mixed sources.