Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

postgres home directory, /var/lib/postgresql, owned by root again

Ouverte
  • Quelque chose ne va pas ?
#1,420 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
docker, postgresql, shell
Domaine
databases, devops

Piste de recherche

Commencez par le script d’entrypoint et reproduisez le comportement de bind-mount à l’aide du fichier compose indiqué, y compris avec un répertoire hôte nouvellement créé. Déterminez en quoi la propriété et les permissions diffèrent entre les images Alpine et Debian ; le travail est terminé lorsque l’utilisateur postgres peut utiliser son répertoire personnel sans perturber le comportement existant des volumes ni introduire une modification incompatible involontaire.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

In 18+, /var/lib/postgresql is the mount target and still the postgres user's home directory. This brings back #274 (fixed by #277) when doing a bind mount on a new directory.

I have this issue again with v18. I started over with a fresh container and newly created volumes. This is my compose file:

services:

  db:
    image: postgres:18-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_PASSWORD=redacted
      - TZ=Europe/Berlin
      - PGTZ=Europe/Berlin
    volumes:
      - /mnt/storage/postgres-data:/var/lib/postgresql
    ports:
      - "5432:5432"

Originally posted by @dkadioglu in #274

If the local directory for the bind mount (like /mnt/storage/postgres-data) doesn't exist before doing a docker compose up, then it will be automatically created by docker as root owned. If users need the .psql_history file, then they'll need to pre-create the directory locally (or chown/chmod after) with permissions such that the postgres user of the image can use it (uid/gid 70 in Alpine; uid/gid 999 in Debian); alternatively, they can run the image as a different user (e.g. user: 1000:1000) that already has permissions to access that directory on the host.

Now that 18 has moved the volume to /var/lib/postgresql/ instead of PGDATA, then it might make sense for us to chown or chmod it in the entypoint script so that the postgres user correctly owns or can at least use their home directory. 🤔 It could be a breaking change though, so we'll have to give it some thought.

Langage dominant
Shell
Étoiles
2.5k
Forks
1.2k
Aucune PR mergée en 30 j

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de docker-library/postgres

Toutes les issues de docker-library/postgres

Issues similaires

Plus d'issues Shell/Bash

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.