redis-like images cannot persist on bind mounts (chown: Operation not permitted) and dragonfly:latest exceeds the 1 GiB default memory cap

[itxtoledo]

Two independent problems prevent redis-style images from running on mocker with persisted data — both reproduced with a full test matrix:

1. Bind mounts break images whose entrypoint chowns the data dir: any bind mount (-v /host/path:/data) makes the entrypoint's chown fail with Operation not permitted (virtiofs) and the container exits. Affects both docker.dragonflydb.io/dragonflydb/dragonfly:latest and the official redis:7. mocker-managed named volumes are NOT affected (chown passes).
2. Dragonfly:latest also hits the 1 GiB default memory cap: the default 4 proactor threads require 1.00 GiB, but the default container limit exposes only ~1003 MiB, so it exits with There are 4 threads, so 1.00GiB are required. Exiting... — even with no volume. redis:7 has no such issue.

Test matrix (mocker 0.9.3, macOS 26+ / Apple Silicon)

Image / config	No volume	Named volume (mocker run -v name:/data)	Bind mount (-v /host:/data)
dragonfly:latest (default 4 threads)	❌ memory cap	❌ memory cap	❌ chown
dragonfly:latest -m 2G	✅ serves	–	–
dragonfly:latest --proactor_threads=2	✅ serves	✅ serves	❌ chown
redis:7	✅ serves	✅ serves	❌ chown
biarms/mysql:5.7 (bind mount /var/lib/mysql)	–	–	✅ serves

Reproduction

# Bind mount -> chown failure, container Exited (both images)
mkdir -p /tmp/redis-data
mocker run -d --name r-bind -p 46401:6379 -v /tmp/redis-data:/data redis:7
mocker logs r-bind
# -> chown: changing ownership of '.': Operation not permitted
mocker run -d --name d-bind -p 46402:6379 -v /tmp/redis-data:/data docker.dragonflydb.io/dragonflydb/dragonfly:latest
mocker logs d-bind
# -> chown: changing ownership of '.': Operation not permitted

# Dragonfly without volume -> memory cap failure
mocker run -d --name d-plain -p 46403:6379 docker.dragonflydb.io/dragonflydb/dragonfly:latest
mocker logs d-plain
# -> Found 1003.83MiB available memory. Setting maxmemory to 803.06MiB
# -> There are 4 threads, so 1.00GiB are required. Exiting...

# Working: named volume (chown passes) or no volume + fewer threads / more memory
mocker run -d --name d-ok -p 46404:6379 -v df-data:/data docker.dragonflydb.io/dragonflydb/dragonfly:latest --proactor_threads=2
mocker run -d --name d-ok2 -m 2G -p 46405:6379 docker.dragonflydb.io/dragonflydb/dragonfly:latest
mocker run -d --name r-ok -p 46406:6379 -v r-data:/data redis:7
# -> all serve

Key observations

• Bug 1 is general to bind mounts, not dragonfly-specific: the official redis:7 fails identically; only images whose entrypoint tolerates a failed chown (e.g. biarms/mysql:5.7) work on bind mounts. mocker-managed named volumes pass the chown for both dragonfly and redis:7, so persistence works there.
• Bug 2 is the closed-issue Container memory hard-capped at 1 GiB (no swap); --memory ignored and compose mem_limit stripped #62 memory cap: dragonfly's default 4 threads need 1.00 GiB; the cap provides ~1003 MiB. -m 2G or --proactor_threads=2 fixes it.

Environment

• mocker 0.9.3 (us/tap/mocker, brew)
• macOS 26+ / Apple Silicon, Apple Containerization runtime (virtiofs mounts)
• Images: docker.dragonflydb.io/dragonflydb/dragonfly:latest (df-v1.39.0), redis:7

Workaround

• Persistence: use a named volume (mocker run -v name:/data or compose with a volume that mocker manages as a real named volume); avoid bind mounts for redis-like images.
• Dragonfly memory: add --proactor_threads=2 or -m 2G to the run/compose command.

💘 Generated with Crush

[us]

Great matrix, thanks — both findings reproduce and they have different owners.

Bind-mount chown: bind mounts go to the container over virtiofs, and virtiofs on macOS does not allow the guest to change ownership of host-backed files — the same chown: Operation not permitted hits Postgres and friends on the upstream runtime too (apple/container#333, docker/for-mac#6243). That's why images whose entrypoint tolerates a failed chown work and redis-like ones don't. Named volumes are backed differently (a real Linux filesystem), which is why chown succeeds there — for redis-like images a named volume is the supported way to persist, and we're planning to move all mocker-managed volumes onto that same backing so the distinction disappears.

Dragonfly memory: the ~1 GiB is the runtime's default VM memory when no -m is given; mocker passes -m through untouched. -m 2G (or --proactor_threads=2) is the intended way to run dragonfly, same as on any memory-capped runtime. We'll make the default cap more visible in the docs so this fails less mysteriously.

Keeping this open to track the named-volume work.