Error while creating mount source path after docker desktop update to v4.35

Hello everyone, after updating Docker Desktop to version 4.35, the well-known problem with launching on Ubuntu 24.04 was solved. Unfortunately, I started to catch an error when starting a container to work with potsgres, although I did not have it before the update.

(HTTP code 500) server error - error while creating mount source path '/host_mnt/home/arthur/docker/postgres_data': mkdir /host_mnt/home/arthur/docker/postgres_data: file exists

I tried to create a backup copy of the postgres_data directory, and then delete it, then I got a similar error, which said that there are permission denied for create the directory

I also get an error when running via cli (see screenshot):

I am also attaching docker-compose.yml

version: "3.9"

services:
  postgres:
    container_name: pg_db
    image: postgres:15
    ports:
      - "5432:5432"
    volumes:
      - ./postgres_data:/var/lib/postgresql/data/
    env_file:
      - docker.env
 
  pgadmin:
    container_name: pgadmin
    image: dpage/pgadmin4:6.0
    ports:
      - "5050:80"
    env_file:
      - docker.env
    depends_on:
      - postgres

  redis:
    container_name: redis
    image: "redis:alpine"
    ports:
      - "6379:6379"

  redis-commander:
    container_name: redis_commander
    image: rediscommander/redis-commander:latest
    environment:
      - REDIS_HOSTS=local:redis:6379
    ports:
      - "8081:8081"
    depends_on:
      - redis
 
networks:
  postgres:
    driver: bridge

I changed the title to be more descriptive.

It looks like a bug, but I don’t use Docker Desktop on Linux so I can’t test it now. I can still recommend changing the bind mount to this long syntax for the postgres service

services:
  postgres:
    # ...
    volumes:
      - type: bind
        source: ./postgres_data
        target: /var/lib/postgresql/data/

Since the long syntax doesn’t try to create the folder automatically. If something is wrong with the short syntax in the new version, this could work. If it doesn’t help, then I don’t know yet. The fact that it says “file exists” indicates the mkdir is executed when the source is already there. If the error message is correct, this is my best idea.

1 Like

Did my recommendation work? Just now I got a strange error message on macOS which could be related. The difference in my case was that it said “operation not permitted” not “file exists”, but it seems to be the same root cause

Update:

In my case it happened because the process in the container didn’t have right to read the subfolder, sinne it was only for the owner. I only recognized it when I mounted the parent folder, but otherwise I got the “mkdir” error message with the “operation not permitted” so maybe it was no the same root cause after all.

1 Like

Hi, as an experiment, I set for the folder where I have the docker-compose.yml file and volume for postgres.

chmod -R 777 my_dir

Then when I run

docker compose up -d

The error log disappeared, and all containers start successfully, judging by the logs in the console (see screenshot)

But when I go to docker-desktop, I see that the container with postgres is stopped.

Then, for the experiment, I deleted my volume directory for postgres. And then the container started successful.

I repeat, everything was for an experiment, information about which may be useful in the future, and I do not consider the steps I described to be correct.

As for your proposed solution above, it didn’t help me.

If Postgres stopped it probably had error messages in the container logs which could have helped, but the original mount issue is stil something I can’t explain. You can try to report it on GitHub too
GitHub - docker/desktop-linux: Bug reports for Docker Desktop for Linux. Since setting the permissions to 777 solved the mount problem, maybe it is related to my issue. To be honest I don’t remember how it worked before. I think I mounted my Downloads folder in the past, but that issue could alos be caused by macOS. A simple postgres folder on Linux should be mountable.