Initialize PostgreSQL Container with docker-entrypoint-initdb.d script - postgresql

Question

I am trying to create a PostgreSQL 11.5 docker container. In doing so, I want to run a SQL script that creates the necessary users, tables, etc. However, whenever the container starts I see the following error:
The files belonging to this database system will be owned by user "postgres".
This user must also own the server process.
The database cluster will be initialized with locale "en_US.utf8".
The default database encoding has accordingly been set to "UTF8".
The default text search configuration will be set to "english".
Data page checksums are disabled.
fixing permissions on existing directory /var/lib/postgresql/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
selecting default shared_buffers ... 128MB
selecting default timezone ... Etc/UTC
selecting dynamic shared memory implementation ... posix
creating configuration files ... ok
running bootstrap script ... ok
performing post-bootstrap initialization ... ok
syncing data to disk ... ok
Success. You can now start the database server using:
pg_ctl -D /var/lib/postgresql/data -l logfile start
WARNING: enabling "trust" authentication for local connections
You can change this by editing pg_hba.conf or using the option -A, or
--auth-local and --auth-host, the next time you run initdb.
****************************************************
WARNING: No password has been set for the database.
This will allow anyone with access to the
Postgres port to access your database. In
Docker's default configuration, this is
effectively any other container on the same
system.
Use "-e POSTGRES_PASSWORD=password" to set
it in "docker run".
****************************************************
waiting for server to start....2019-09-16 17:16:26.568 UTC [42] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2019-09-16 17:16:26.677 UTC [43] LOG: database system was shut down at 2019-09-16 17:16:25 UTC
2019-09-16 17:16:26.691 UTC [42] LOG: database system is ready to accept connections
done
server started
/usr/local/bin/docker-entrypoint.sh: running /docker-entrypoint-initdb.d/init.sql
/docker-entrypoint-initdb.d/init.sql: Permission denied
My Dockerfile looks like this:
FROM postgres:11.5
ADD ./scripts/init.sql /docker-entrypoint-initdb.d/
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 5432
CMD ["postgres"]
And, my init.sql file looks like this:
CREATE USER mydb WITH PASSWORD 'password';
CREATE DATABASE mydb;
GRANT ALL PRIVILEGES ON DATABASE mydb TO mydb;
You'll notice neither of them does anything terribly complicated. However, I'm still getting the permission denied error. I've connected to the running container and confirmed that the init.sql file is in place on the filesystem. Any idea what I could be doing wrong here?

Answer 1

So from this Dockerfile I assume the user is postgress.
Try with this Dockerfile
FROM postgres:11.5
USER postgres
RUN whoami
ADD ./scripts/init.sql /docker-entrypoint-initdb.d/
ENTRYPOINT ["docker-entrypoint.sh"]
EXPOSE 5432
CMD ["postgres"]
update:
Seems like the file not owned by Postgres user.
Try to set permission
ADD ./scripts/init.sql /docker-entrypoint-initdb.d/
RUN chown postgres:postgres /docker-entrypoint-initdb.d/init.sql

Answer 2

Initialize Postgres container with Data
Create a docker-compose.yml
version: '2'
services:
postgress-postgresql:
image: postgres:11.3
volumes:
# - ~/volumes/jhipster/postgress/postgresql/:/var/lib/postgresql/data/
- ./init.sql:/docker-entrypoint-initdb.d/init.sql
environment:
- POSTGRES_USER=postgress
- POSTGRES_PASSWORD=
ports:
- 5432:5432
Create a init.sql with the script
CREATE USER platops WITH PASSWORD 'platops';
CREATE DATABASE platopsdb;
GRANT ALL PRIVILEGES ON DATABASE platopsdb TO platops;
RUN with docker-compose up -d

Answer 3

I had the same issue, mounted a .sh file via docker volumes. I checked permissions via ls -lah, in my case it was just -rw-r-----.
Using chmod 644 filename solved my issue.

Answer 4

The underlaying problem in our case was that the sql script was stored on a ntfs partition mounted with ntfs-3g which by default has got permissions' functionality disabled (https://superuser.com/questions/451475/chmod-doesnt-work). Running it on a normal ext4 partition solved the problem.

Answer 5

Disclaimer: I am aware it is not an answer to the question but it might shed some light why for some people it works and for others it does not.
Inside our team, it's working perfectly for the guy who's username is "admin" (literally). It does not work for me nor for out deployment server. Where our usernames are different.
Using "sudo" did not have any impact. It did not break his it did not fix ours.
My machine and his are MacOS. The server is Ubuntu.