Permission Denied: '/Var/Lib/Pgadmin/Sessions' in Docker

Permission denied: '/var/lib/pgadmin/sessions' in Docker

Okay. looks like problem appears when you try to run pgadmin service.

This part

  ### pgAdmin ##############################################
  pgadmin:
    image: dpage/pgadmin4:latest
    environment:
      - "PGADMIN_DEFAULT_EMAIL=${PGADMIN_DEFAULT_EMAIL}"
      - "PGADMIN_DEFAULT_PASSWORD=${PGADMIN_DEFAULT_PASSWORD}"
    ports:
      - "${PGADMIN_PORT}:80"
    volumes:
      - ${DATA_PATH_HOST}/pgadmin:/var/lib/pgadmin
    depends_on:
      - postgres
    networks:
      - frontend
      - backend

As you can see you trying to mount local directory ${DATA_PATH_HOST}/pgadmin into container's /var/lib/pgadmin

    volumes:
      - ${DATA_PATH_HOST}/pgadmin:/var/lib/pgadmin

As you can read in this article your local ${DATA_PATH_HOST}/pgadmin directory's UID and GID must be 5050. Is this 5050?

You can check it by running

ls -l ${DATA_PATH_HOST}

Output will be like

drwxrwxr-x 1 5050 5050 12693 Nov 11 14:56 pgadmin

or

drwxrwxr-x 1 SOME_USER SOME_GROUP 12693 Nov 11 14:56 pgadmin

if SOME_USER's and SOME_GROUP's IDs are 5050, it is okay. 5050 as is also okay. If not, try to do as described in article above.

sudo chown -R 5050:5050 ${DATA_PATH_HOST}/pgadmin

Also you need to check is environment variable exists:

# run it as same user as you running docker-compose
echo ${DATA_PATH_HOST}

If output will be empty you need to set ${DATA_PATH_HOST} or allow docker to read variables from file. There are many ways to do it.

How to solve Operation not permitted: '/var/lib/pgadmin' error in laradock at Windows Subsystem for Linux?

You may try this:

sudo chown -R 5050:5050 ~/.laradock/data/pgadmin

Then restart the container. Cause in the container with:

uid=5050(pgadmin) gid=5050(pgadmin)

and

drwx------ 4 pgadmin  pgadmin  56 Jan 27 08:25 pgadmin

OSError: [Errno 13] Permission denied: '/var/lib/pgadmin'

Permission error means the user 'michael' (/var/lib has drwxr-xr-x) has the permission to execute but doesn't have the permission to write on the folder (according to your comment of the folder info below).
One of the solutions you can use to be able to access freely the folder would be something like:

chown -R michael:root /path/to/the/directory

The second part of the answer, you've figured it out @Michael.
downloading pgadmin by using the command:

wget https://ftp.postgresql.org/pub/pgadmin/pgadmin4/v1.5/pip/pgadmin4-1.5-py2.py3-none-any.whl 

and then execute command:

pip install pgadmin4*.whl.

Getting permission exception when run docker-compose up with dpage/pgadmin4 image

I had the same problem. I could solve it by mounting the volume at a slightly different location:

    volumes:
      - pgadmin:/var/lib/pgadmin4/storage

Note that in your script it was mounted at /var/lib/pgadmin/storage.

Kubernetes persistent volume mount for PgAdmin

I've replicated your issue. Root cause is with PgAdmin issue, not Kubernetes. Pods will be deployed without issue. You will receive error as container won't be able to create folder inside folder /var/lib. If you will check pgadmin pod logs - kubectl logs <pgadmin-pod> you will see errors like:

$ kubectl logs pgadmin-d569b67fd-8rnkc
WARNING: Failed to set ACL on the directory containing the configuration database:
           [Errno 1] Operation not permitted: '/var/lib/pgadmin'
HINT   : You may need to manually set the permissions on
         /var/lib/pgadmin to allow pgadmin to write to it.
ERROR  : Failed to create the directory /var/lib/pgadmin/sessions:
           [Errno 13] Permission denied: '/var/lib/pgadmin/sessions'
HINT   : Create the directory /var/lib/pgadmin/sessions, ensure it is writeable by
         'pgadmin', and try again, or, create a config_local.py file
         and override the SESSION_DB_PATH setting per
         https://www.pgadmin.org/docs/pgadmin4/4.26/config_py.html
sudo: setrlimit(RLIMIT_CORE): Operation not permitted

If you will check /var/lib/ folder permissions you will se that you can only Read and Execute, so you won't be able to create in this folder anything (as default, you will be logged as pgadmin user).

drwxr-xr-x    1 root     root          4096 Sep  5 14:01 lib

Depends on your needs you can resolve it in a few ways. As fastest workaround you can just change path to folder which allows Write, like tmp.

drwxrwxrwt    1 root     root          4096 Oct  5 14:28 tmp

In YAML it would looks like:

  containers:
    - name: pgadmin4
      image: dpage/pgadmin4
      volumeMounts:
        - mountPath: /var/tmp/pgadmin
          name: pgadminstorage

When you will check logs, there won't be any issues.

$ kubectl logs pgadmin-6bb74cffb8-6q9tr
NOTE: Configuring authentication for SERVER mode.

sudo: setrlimit(RLIMIT_CORE): Operation not permitted
[2020-10-05 14:28:15 +0000] [1] [INFO] Starting gunicorn 19.9.0
[2020-10-05 14:28:15 +0000] [1] [INFO] Listening at: http://[::]:80 (1)
[2020-10-05 14:28:15 +0000] [1] [INFO] Using worker: threads
/usr/local/lib/python3.8/os.py:1023: RuntimeWarning: line buffering (buffering=1) isn't supported in binary mode, the default buffer size will be used
  return io.open(fd, *args, **kwargs)
[2020-10-05 14:28:15 +0000] [89] [INFO] Booting worker with pid: 89
user@cloudshell:~/pgadmin (project)$

Regarding PgAdmin permissions issue there was already a few topics on StackOverflow or Github like:
OSError: [Errno 13] Permission denied: '/var/lib/pgadmin'

pgadmin exit code 3 PermissionError: [Errno 13] Permission denied: '/var/lib/pgadmin/sessions'

[stable/pgadmin] files in /var/lib/pgadmin/sessions crash the pod

In short, you could try to manually change permissions or use specific user.

In addition, if you are using Cloud environment, you could think about using CloudSQL, instead of trying to put database into cloud. For example PostgreSQL with GKE

EDIT

As per @Ryan comment below this answer, you can also use Init Containers to change /var/lib/ permissions. Each init container must complete successfully before the next one starts and it runs before app containers in a pod.

specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image.

Accessing PostgreSQL on docker container from pgAdmin4 in another docker container

Inside a container, the loopback address (localhost or 127.0.0.1) refers to "this container". When you try to connect to 127.0.0.1 inside the pgAdmin4 container, it fails because your Postgres service is not running inside the pgAdmin4 container.

The easiest way to make this work is to put both of your containers on a user defined network, in which case they can simply refer to each other by name.

Start by creating a network:

docker network create dbnet

Then launch the postgres container on that network:

docker run --rm --name pg-docker -e POSTGRES_PASSWORD=docker \
    --net dbnet \
    -v $HOME/vols/postgres:/var/lib/postgresql/data \
    -d -p 5432:5432  postgres

And finally launch the pgAdmin4 container on that network:

docker run --rm --name pgadmin4 -p 5050:80 \    
    --net dbnet \
    -v $HOME/vols/pgadmin4:/var/lib/pgadmin \
    -e 'PGADMIN_DEFAULT_EMAIL=amiry@manexapp.com' \
    -e 'PGADMIN_DEFAULT_PASSWORD=12345678' \
    -d dpage/pgadmin4

Now when you access your pgadmin ui, you can connect to the host pg-docker instead of localhost.

PostgreSQL 11 configurations doesn't allow pgAdmin4 to connect

Check SELinux audit logs - https://fedoraproject.org/wiki/SELinux_FAQ#How_do_I_find_out_whether_SELinux_is_denying_access_for_any_software.3F

I see denials on my test CentOS 7 system:

type=AVC msg=audit(1560101981.565:1942): avc:  denied  { name_connect } for  pid=63140 comm="httpd" dest=5432 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:postgresql_port_t:s0 tclass=tcp_socket permissive=0
type=SYSCALL msg=audit(1560101981.565:1942): arch=c000003e syscall=42 success=no exit=-13 a0=15 a1=7f741c06dfe0 a2=10 a3=7f742f9147b8 items=0 ppid=63139 pid=63140 auid=4294967295 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 tty=(none) ses=4294967295 comm="httpd" exe="/usr/sbin/httpd" subj=system_u:system_r:httpd_t:s0 key=(null)

I guess, you will have similar problem in your Fedora - you will need to tweak used SELinux policy.

---

Related Topics