Colima v0.2.2 trying to run a simple java springboot application - fails with readonly filesystem about colima HOT 19 CLOSED

ok - I have come back to testing this with the latest HEAD version installed via brew install --head colima as suggested above.
I am on macos Monterey 12.1
I started colima with colima start --mount $HOME:w

I am using a minimalistic docker-compose file:

version: '3'
services:
  db:
    image: "postgres:13.4"
    container_name: api-db
    volumes:
      - ./postgres-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=apiDbUser
      - POSTGRES_PASSWORD=apiDbPassword
      - POSTGRES_DB=apiDb
    ports:
      - "5433:5432"

The error that I get is:

Attaching to api-db
api-db  | chown: changing ownership of '/var/lib/postgresql/data': Permission denied
api-db exited with code 1

I have also tried it with mkdir postgres-data; chmod 777 postgres-data; docker-compose up --build --remove-orphans - same issue

from colima.

Version 0.3.0 is actually going to default to writeable volumes, so most users would not need to modify the volumes.

@vraravam For now, I would recommend specifying volume mounts only at initial startup.
I have encountered some inconsistencies with Lima when modifying mounts of an existing VM.

I will dig into this a bit better to find the root cause.

from colima.

The chown is something you have customized somewhere or is the base postgresql docker image?

Its not something that I have created. I have shown the complete docker-compose.yml in my comment. This seems to be coming from the postgresql docker image.

Did you fixed this issue?

from colima.

The same Dockerfile, etc are running on my colleague's machine - where they use the Docker Desktop for Mac, while I am using colima.

from colima.

The same Dockerfile, etc are running on my colleague's machine - where they use the Docker Desktop for Mac, while I am using colima.

It is not possible to help you with just the Docker file. This is the image why the problem is occuring with the container when the springboot application is started.

Where are you mounting the the /app volume? By default CoLima is using only the /tmp folder in write mode. If you mount it in your home directory this is by default read-only as the error you are showing.

from colima.

I have tried mounting both the $HOME folder from my macos as writable (though this is not the preferred option).

I have also tried creating a new folder just as a sibling of my current project folder and setting that as GRADLE_USER_HOME and passing that as a writable mount.

Both the above were tried while starting colima with colima start --mount <directory>:w

from colima.

Some more info:
My project is in ~/dev/projects/sample-app

The gradle cache locations that I tried: ~/.gradle and ~/dev/projects/.gradle

is there any other info that you would like to be able to help?

from colima.

I have also tried sudo chmod -R 777 for each location of the gradle cache. This is the error that I get:

| Could not initialize native services.
|
| * Try:
| > Run with --info or --debug option to get more log output.
| > Run with --scan to get full insights.
|
| * Exception is:
| org.gradle.internal.service.ServiceCreationException: Could not initialize native services.
| 	at org.gradle.internal.nativeintegration.services.NativeServices.initialize(NativeServices.java:159)
| 	at org.gradle.internal.nativeintegration.services.NativeServices.initializeOnDaemon(NativeServices.java:126)
| 	at org.gradle.launcher.daemon.bootstrap.DaemonMain.doAction(DaemonMain.java:107)
| 	at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:50)
| 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
| 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
| 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
| 	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
| 	at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60)
| 	at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37)
| 	at org.gradle.launcher.daemon.bootstrap.GradleDaemon.main(GradleDaemon.java:22)
| Caused by: net.rubygrapefruit.platform.NativeException: Failed to load native library 'libnative-platform.so' for Linux amd64.
| 	at net.rubygrapefruit.platform.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:67)
| 	at net.rubygrapefruit.platform.Native.init(Native.java:56)
| 	at org.gradle.internal.nativeintegration.services.NativeServices.initializeNativeIntegrations(NativeServices.java:170)
| 	at org.gradle.internal.nativeintegration.services.NativeServices.initialize(NativeServices.java:155)
| 	... 10 more
| Caused by: java.io.FileNotFoundException: /home/gradle/.gradle/native/e1d6ef7f7dcc3fd88c89a11ec53ec762bb8ba0a96d01ffa2cd45eb1d1d8dd5c5/linux-amd64/libnative-platform.so.lock (Operation not permitted)
| 	at java.base/java.io.RandomAccessFile.open0(Native Method)
| 	at java.base/java.io.RandomAccessFile.open(RandomAccessFile.java:345)
| 	at java.base/java.io.RandomAccessFile.<init>(RandomAccessFile.java:259)
| 	at java.base/java.io.RandomAccessFile.<init>(RandomAccessFile.java:214)
| 	at net.rubygrapefruit.platform.internal.NativeLibraryLocator.find(NativeLibraryLocator.java:46)
| 	at net.rubygrapefruit.platform.internal.NativeLibraryLoader.load(NativeLibraryLoader.java:45)
| 	... 13 more
|
|
| * Get more help at https://help.gradle.org
|
|
| * Try:
| > Run with --stacktrace option to get the stack trace.
| > Run with --info or --debug option to get more log output.
| > Run with --scan to get full insights.
|
| * Get more help at https://help.gradle.org
XXXXX-api exited with code 1

from colima.

@abiosoft - is there any way I can test the new 0.3.0 version?

I am not sure what you mean by "specifying volume mounts only at initial startup". I thought I am doing only that with colima start --mount ....?

from colima.

@abiosoft - is there any way I can test the new 0.3.0 version?

@vraravam only by building from source from the feature/alpine branch. You need to have Go installed.

Cleanup

You need to delete existing instance(s) due to the change in the underlying distro from Ubuntu to Alpine.
After that brew uninstall colima to avoid conflicts.

Build Instructions

git clone https://github.com/abiosoft/colima --branch feature/alpine
cd colima
make
sudo make install

The version should match the most recent commit on the repo.

$ colima version
colima version v0.2.2-16-gcb49999
git commit: cb499992ef36805ac585f0a41c83bf248c4c6f17

Kindly give it a try and see if it works.

from colima.

ok - its been a few years since i programmed in golang. Will give it a try. Tx are these instructions in a CONTRIBUTING.md file somewhere - where other interested devs can contribute?

from colima.

ok - its been a few years since i programmed in golang. Will give it a try. Tx are these instructions in a CONTRIBUTING.md file somewhere - where other interested devs can contribute?

Building from source is actually straightforward as you need nothing else other than Go.
brew install golang should suffice.

from colima.

@vraravam you can now simply install it with brew install --head colima.

from colima.

I installed the latest head and it writes.
But still there's an issue with UID/GIDs in volumes mounted from physical host. It doesn't work so you have to set permissions on physical host.

Please see below how it looks on my side:

(venv) ^_^[xn@zdt:~/devel/colima]$ mkdir data
(venv) ^_^[xn@zdt:~/devel/colima]$ chmod 777 data
(venv) ^_^[xn@zdt:~/devel/colima]$ colima ssh
colima:/Users/xn/devel/colima$ mkdir data/test
colima:/Users/xn/devel/colima$ ls -al
total 4
drwxrwxrwx    1 xn       dialout         96 Dec 23 15:23 data
colima:/Users/xn/devel/colima$ chown 999 data
chown: data: Permission denied
colima:/Users/xn/devel/colima$ sudo chown 999 data
chown: data: Permission denied
colima:/Users/xn/devel/colima$ sudo chown 999 data/test
chown: data/test: Permission denied

from colima.

It is because there is somewhere a chown in the Docker image. It is not allowed in the actual sshfs.
But I'm using postgresql with a volume and I don't have this problem.

The chown is something you have customized somewhere or is the base postgresql docker image?

from colima.

The chown is something you have customized somewhere or is the base postgresql docker image?

Its not something that I have created. I have shown the complete docker-compose.yml in my comment. This seems to be coming from the postgresql docker image.

from colima.

Did you fixed this issue?

I still faced this issue a couple of days ago. Can try once more and report back

from colima.

Finally, my friend & colleague helped me fix the issue with the postgres base image. The final working copy of the docker-compose.yml is:

version: '3'
services:
  db:
    image: "postgres:13.4"
    container_name: api-db
    user: postgres
    volumes:
      - ./postgres-data:/var/lib/postgresql
    environment:
      - POSTGRES_USER=apiDbUser
      - POSTGRES_PASSWORD=apiDbPassword
      - POSTGRES_DB=apiDb
    ports:
      - "5433:5432"

Note the differences that are mandatory:

1. The user option has to be set explicitly. Using the default root doesn't seem to work since the base image postgres:13.4 sets up a non-root user for the process
2. The mounted directory has to be the parent of the data directory, not the data directory itself! (This used to work when using DDfM, but with colima 0.3.1, this seems to fix the issue.)

from colima.

from colima.