Docker containers don't have r/w permissions

[artggd]

Hi,

I'm very excited about this project, so I tried using with my company's current stack.
We're using docker with docker-compose. Working mainly with php-fpm and nginx.

docker-compose up works fine, but as soon as I try to install any dependency within a docker container, I get a permission denied.
Same goes for reading, I managed to forward 443 port on my host machine but nginx (running in docker, running in Lima) cannot read the index.php file.

Tested on a 2017 macbook pro, running on a 2,5 GHz Intel Core i7. macOS version is 10.14.16.

Following is my lima.yaml file, I only made the home directory writable:

~/.lima/default/lima.yaml

  # Arch: "default", "x86_64", "aarch64".
  # "default" corresponds to the host architecture.
  arch: "default"
  
  # An image must support systemd and cloud-init.
  # Ubuntu and Fedora are known to work.
  # Default: none (must be specified)
  images:
    # Try to use a local image first.
    - location: "~/Downloads/hirsute-server-cloudimg-amd64.img"
      arch: "x86_64"
    - location: "~/Downloads/hirsute-server-cloudimg-arm64.img"
      arch: "aarch64"
  
    # Download the file from the internet when the local file is missing.
    - location: "https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-amd64.img"
      arch: "x86_64"
    - location: "https://cloud-images.ubuntu.com/hirsute/current/hirsute-server-cloudimg-arm64.img"
      arch: "aarch64"
  
  # CPUs: if you see performance issues, try limiting cpus to 1.
  # Default: 4
  cpus: 4
  
  # Memory size
  # Default: "4GiB"
  memory: "4GiB"
  
  # Disk size
  # Default: "100GiB"
  disk: "100GiB"
  
  # Expose host directories to the guest
  # Default: none
  mounts:
    - location: "~"
      # CAUTION: `writable` SHOULD be false for the home directory.
      # Setting `writable` to true is possible, but untested and dangerous.
      writable: true
    - location: "/tmp/lima"
      writable: true
  
  ssh:
    # A localhost port of the host. Forwarded to port 22 of the guest.
    # Currently, this port number has to be specified manually.
    # Default: none
    localPort: 60022
  
  firmware:
    # Use legacy BIOS instead of UEFI.
    # Default: false
    legacyBIOS: false
  
  video:
    # QEMU display, e.g., "none", "cocoa", "sdl".
    # As of QEMU v5.2, enabling this is known to have negative impact
    # on performance on macOS hosts: https://gitlab.com/qemu-project/qemu/-/issues/334
    # Default: "none"
    display: "none"
  
  containerd:
    # Enable system-wide (aka rootful)  containerd and its dependencies (BuildKit, Stargz Snapshotter)
    # Default: false
    system: false
    # Enable user-scoped (aka rootless) containerd and its dependencies
    # Default: true
    user: true
  
  # Provisioning scripts need to be idempotent because they might be called
  # multiple times, e.g. when the host VM is being restarted.
  # provision:
  #   # `system` is executed with the root privilege
  #   - mode: system
  #     script: |
  #       #!/bin/bash
  #       set -eux -o pipefail
  #       export DEBIAN_FRONTEND=noninteractive
  #       apt-get install -y vim
  #   # `user` is executed without the root privilege
  #   - mode: user
  #     script: |
  #       #!/bin/bash
  #       set -eux -o pipefail
  #       cat <<EOF > ~/.vimrc
  #       set number
  #       EOF
  
  # probes:
  #  # Only `readiness` probes are supported right now.
  #  - mode: readiness
  #    description: vim to be installed
  #    script: |
  #       #!/bin/bash
  #       set -eux -o pipefail
  #       if ! timeout 30s bash -c "until command -v vim; do sleep 3; done"; then
  #         echo >&2 "vim is not installed yet"
  #         exit 1
  #       fi
  #    hint: |
  #      vim was not installed in the guest. Make sure the package system is working correctly.
  #      Also see "/var/log/cloud-init-output.log" in the guest.

Any help would be appreciated 🙂

[AkihiroSuda]

Could you provide full commands to reproduce the issue

[artggd]

Thanks for your reply, here's how to reproduce:

1. Start limactl and run a shell

$ limactl start
$ lima

2. Run a bash session in a docker container, binding a volume app to it

$ docker run --volume $PWD/myproject:/app --rm -it nginx:latest bash

3. ls -lad app to see the files permissions on the volume should give you this:

root@b6444cc8d609:/# ls -lad app
drwxr-xr-x 1 root root 64 Jun 29 12:43 app

4. su as www-data

root@b6444cc8d609:/# su -s /bin/bash www-data

5. Try to move to app directory

www-data@b6444cc8d609:/$ cd app
bash: cd: app: Permission denied

-> The app folder is not readable by www-data, only root can access it.

[AkihiroSuda]

Expected behavior. Please copy files when you need to control the permission.

[fhuitelec]

Please copy files when you need to control the permission.

From what described @artggd, it seems there is a permission corruption rather than a need to get control over permissions.

The /app folder in the container has read and execute bits for all (user, group & other): why a non-root user (ie. www-data) could not enter the directory with such permissions?

Expected behavior.

With the emphasis I did on the permission issue, is this still expected?

If yes, could you point us in the component in lima from which this behaviour comes from (the reverse SSHFS with sshoker maybe?)

Finally, if this is expected behaviour on Lima, this is quite not the case from a user stand point: would you agree to add this in the README's troubleshooting section?

[fhuitelec]

@AkihiroSuda, did you get a chance to review my last comment?