rancher-desktop: chown error on bind mount when trying to launch postgres via docker compose

You can include the following content in ~/Library/Application\ Support/rancher-desktop/lima/_config/override.yaml:

mountType: 9p
mounts:
  - location: "~"
    9p:
      securityModel: mapped-xattr
      cache: "mmap"

It should allow this to work (you must restart Rancher Desktop to apply this setting).

Caveats: any symlinks on your host system will be seen as the referenced object in the VM/container. If there’s a symlink loop, and something tries to follow it, it’ll eat its own tail (potentially slowly depending on how things behave).

The databases I’m playing w/ (postgres, redis, neo4j) don’t generally deal in symlinks, so I believe it’s a satisfactory configuration for my database use cases. (It may create a mess for all of my other use cases, but that remains to be seen.)

FYI…

$ cat ~/Library/Application\ Support/rancher-desktop/lima/_config/override.yaml
mountType: 9p

$ docker compose up
[+] Running 4/0
 ⠿ Network rabbitmq_default        Created                                                                                                                                                                        0.0s
 ⠿ Container rabbitmq-rabbitmq1-1  Created                                                                                                                                                                        0.0s
 ⠿ Container rabbitmq-rabbitmq3-1  Created                                                                                                                                                                        0.0s
 ⠿ Container rabbitmq-rabbitmq2-1  Created                                                                                                                                                                        0.0s
Attaching to rabbitmq-rabbitmq1-1, rabbitmq-rabbitmq2-1, rabbitmq-rabbitmq3-1
...
rabbitmq-rabbitmq3-1  |   Starting broker... completed with 4 plugins.
rabbitmq-rabbitmq1-1  |   Starting broker... completed with 4 plugins.
rabbitmq-rabbitmq2-1  |   Starting broker... completed with 4 plugins.

Switching over to 9P does indeed solve part of the problem for me. The chown issue disappears but it was replaced with file create issues in my case, changing to loose permissions on all dirs (777) resolved that however.

Still an issue with Rancher Desktop 1.4.1, exactly as described above. This is the only thing preventing me from using Rancher as opposed to Docker.

I too am keen to see this resolved. Having been a Docker Desktop user, and developing on my M1 mac, I have no issues with permissions when starting docker containers. All my project files are owned by my id, however the docker containers that start (eg: Postgres or mysql) while they may attempt to chown and change permissions on files as part of their normal startup process - those attempts don’t fail and those containers run happily.

On rancher desktop, those file mod permissions fail with permission denied errors - and if I change the uid/gid (from the host) to what the process is running on in the container, then those files are not visible and file not found errors pursue.

I changed from Docker Desktop on my company issued device, as I didn’t want my company to think that I was using commercial software without meeting the license requirements, nor did I want Docker to think I was doing the same.

As much as I am glad that Rancher Desktop exists, I cannot use it as a functional replacement to Docker Desktop 😦

EDIT: I just tried the 9p in the override.yml as suggested above - and it does go along way to making Rancher Desktop a functional replacement to Docker Desktop. I had an issue with permissions, which I had to fix “in container” but once done, things were working better. 😄

This ended up being a problem with colima on my m1 mac for me and ultimately with the lima vm, I had to upgrade to ventura and switch colima to vz vmtype and set my mountype to virtiofs then uninstall colima and lima and reinstall them and the mount worked

steps I took

1. run colima template and set vmType and mountType

# Virtual Machine type (qemu, vz)
# NOTE: this is macOS 13 only. For Linux and macOS <13.0, qemu is always used.
#
# vz is macOS virtualization framework and requires macOS 13
#
# Default: qemu
vmType: vz

# Utilise rosetta for amd64 emulation (requires m1 mac and vmType `vz`)
# Default: false
rosetta: false

# Volume mount driver for the virtual machine (virtiofs, 9p, sshfs).
#
# virtiofs is limited to macOS and vmType `vz`. It is the fastest of the options.
#
# 9p is the recommended and the most stable option for vmType `qemu`.
#
# sshfs is faster than 9p but the least reliable of the options (when there are lots
# of concurrent reads or writes).
#
# Default: virtiofs (for vz), sshfs (for qemu)
mountType: virtiofs

1. uninstall and reinstall colima brew uninstall colima && brew uninstall lima
2. reinstall colima and start it up

brew install colima
colima start

This solved my issue, thanks for posting

You can include the following content in ~/Library/Application\ Support/rancher-desktop/lima/_config/override.yaml:

mountType: 9p
mounts:
  - location: "~"
    9p:
      securityModel: mapped-xattr
      cache: "mmap"

It should allow this to work (you must restart Rancher Desktop to apply this setting).

Caveats: any symlinks on your host system will be seen as the referenced object in the VM/container. If there’s a symlink loop, and something tries to follow it, it’ll eat its own tail (potentially slowly depending on how things behave).

The databases I’m playing w/ (postgres, redis, neo4j) don’t generally deal in symlinks, so I believe it’s a satisfactory configuration for my database use cases. (It may create a mess for all of my other use cases, but that remains to be seen.)

I think this may be an issue with the underlying lima. I experience the exact same behavior using either Rancher Desktop or colima.

Possibly related lima-vm/lima#504

I was able to resolve the issue on mac with the following setup:

I also allow Rancher Desktop to use admin permission and disabled Traefik.

They converted that issue into a discussion https://github.com/lima-vm/lima/discussions/505 marked it as answered.

sshfs isn’t robust (and fast) enough to be used as /var/lib/postgresql. Please use lima nerdctl volume create to create a named volume inside the guest ext4 filesystem.

To me, it doesn’t feel like the answer is addressing the broader concerns raised above.

I’m trying to use Rancher Desktop with the simplest compose file ever and get a similar error:

version: '3'
services:
  redis:
    container_name: rmo-redis
    image: redis:6
    ports:
      - 6379:6379
    command: ['redis-server']
    volumes:
      - ./:/tmp

Running “docker compose up” gives me:

➜  ~/git/scratch/composetest/web git:(main) ✗ docker compose up
[+] Running 1/0
 ⠿ Container rmo-redis  Recreated                                                                                                                                                                      0.0s
Attaching to rmo-redis
rmo-redis  | chown: changing ownership of '.': Permission denied
rmo-redis exited with code 1

It seems like the only solution is to use the mountType: 9p solution described by @QuentinStouffs above, but according to this link - https://github.com/lima-vm/lima/issues/20#issue-895105285 (and our own devs), it’s ridicoulously slow to the point of unusable.

I encountered a similar issue where on Windows hosts the non-root user inside the container no longer had write access to mounts after switching from docker-desktop to rancher-desktop.

I’m using a docker-compose file with the following volume

volumes:
  - ${ROOT_DIRECTORY}/logs:/opt/something/logs

If the directory ${ROOT_DIRECTORY}/logs does not exist on the Windows Host it gets created when I run docker-compose up for the first time. The root user inside the container will be the owner of the /opt/something/logs directory and the non-root user inside the container will only have read access.

If the directory already existed on the Windows hosts (it is not created by Rancher-Desktop), the non root user inside the container also has write access.

I guess there’s some difference in how Rancher-Desktop creates the folder on the host as compared to how Docker-Desktop did it on Windows hosts.

FYI…

$ cat ~/Library/Application\ Support/rancher-desktop/lima/_config/override.yaml
mountType: 9p

$ docker compose up
[+] Running 4/0
 ⠿ Network rabbitmq_default        Created                                                                                                                                                                        0.0s
 ⠿ Container rabbitmq-rabbitmq1-1  Created                                                                                                                                                                        0.0s
 ⠿ Container rabbitmq-rabbitmq3-1  Created                                                                                                                                                                        0.0s
 ⠿ Container rabbitmq-rabbitmq2-1  Created                                                                                                                                                                        0.0s
Attaching to rabbitmq-rabbitmq1-1, rabbitmq-rabbitmq2-1, rabbitmq-rabbitmq3-1
...
rabbitmq-rabbitmq3-1  |   Starting broker... completed with 4 plugins.
rabbitmq-rabbitmq1-1  |   Starting broker... completed with 4 plugins.
rabbitmq-rabbitmq2-1  |   Starting broker... completed with 4 plugins.

Switching over to 9P does indeed solve part of the problem for me. The chown issue disappears but it was replaced with file create issues in my case, changing to loose permissions on all dirs (777) resolved that however.

This will (probably) be fixed when Lima bumps up to version 1.0.

$ ~/Applications/Rancher\ Desktop.app/Contents/Resources/resources/darwin/lima/bin/limactl --version
limactl version 0.9.2-54-ge82db87

Why? Because 9P will be used instead of sshocker by default. Aka virtio-9p-pci in QEMU.

lima-vm/lima#20

https://github.com/lima-vm/lima/blob/master/docs/mount.md

Thanks, I’ve already changed to Docker Desktop. Will install Rancher when this issue solved.

current workaround for me is to set VZ as emulation in preference. so far no downside for my usecase

… and “Volumes/Mount Type” to virtiofs at the same time. Disclaimer: I am also in testing phase for the setting 😃

current workaround for me is to set VZ as emulation in preference. so far no downside for my usecase

Also having this problem but it’s across more than postgres/mongo - random containers of mine are having chown-related issues like this. I attempted the 9p workaround but that made the problem even worse (all of my containers started chaotically crashing/restarting)

Looks like 6 days ago Lima documented using virtiofs lima-vm/lima@c18ae23

It is still unreleased. Also will require macOS 13 (Ventura).