Overlayfs vers Overlay2, Échec sur installation fraîche, pilote de stockage

Des messages d’erreur apparaissent après ./discourse-setup et la saisie de l’hôte, du port smtp, etc., conformément à l’installation officielle.

ENTRÉE pour continuer, ‘n’ pour réessayer, Ctrl+C pour quitter :
letsencrypt.ssl.template.yml activé

Fichier de configuration dans containers/app.yml mis à jour avec succès !

Mises à jour réussies. Reconstruction dans 5 secondes.
Construction de l’application
Votre installation Docker n’utilise pas de pilote de stockage pris en charge. Si nous devions continuer, vous pourriez avoir une installation cassée.
overlay2 est le pilote de stockage recommandé, bien que zfs et aufs puissent également fonctionner.
D’autres pilotes de stockage sont connus pour être problématiques.
Vous pouvez savoir quel système de fichiers vous utilisez en exécutant “docker info” et en regardant la ligne ‘Storage Driver’.

Si vous souhaitez continuer de toute façon en utilisant votre pilote de stockage non pris en charge existant,
lisez le code source de launcher et déterminez comment contourner cette vérification.

Pilote de Stockage Overlayfs vers overlay2

J’ai essayé de suivre le bot de discussion “ask ai” et de rechercher les sujets précédents, tels que :

Mais cela ne fonctionne toujours pas.

root 3085 0.0 0.0 6480 2372 pts/1 S+ 05:27 0:00 grep --color=auto 2658

Impossible d’Installer Docker

J’ai essayé de changer mes fournisseurs de VPS pour DigitalOcean, et deux autres fournisseurs de VPS, mais cela a toujours échoué.

Je pensais que c’était un problème de mon fournisseur de VPS, mais après avoir essayé une installation propre sur Digital Ocean avec quelques gouttelettes fraîches et une installation officielle/standard, cela a toujours échoué. Ensuite, j’ai changé pour deux autres fournisseurs de VPS différents, même chose. :face_with_raised_eyebrow:

Je pensais que c’était ma version d’Ubuntu, mais après avoir essayé les versions Ubuntu 24, 22, 20 et 18, cela a toujours échoué.

Client: Docker Engine - Community
 Version:    29.0.2
 Context:    default
 Debug Mode: false
 Plugins:
  buildx: Docker Buildx (Docker Inc.)
    Version:  v0.30.0
    Path:     /usr/libexec/docker/cli-plugins/docker-buildx
  compose: Docker Compose (Docker Inc.)
    Version:  v2.40.3
    Path:     /usr/libexec/docker/cli-plugins/docker-compose
  model: Docker Model Runner (Docker Inc.)
    Version:  v1.0.0
    Path:     /usr/libexec/docker/cli-plugins/docker-model

Server:
 Containers: 1
  Running: 1
  Paused: 0
  Stopped: 0
 Images: 3
 Server Version: 29.0.2
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Using metacopy: false
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
 CDI spec directories:
  /etc/cdi
  /var/run/cdi
 Swarm: inactive
 Runtimes: io.containerd.runc.v2 runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: fcd43222d6b07379a4be9786bda52438f0dd16a1
 runc version: v1.3.3-0-gd842d771
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: builtin
  cgroupns
 Kernel Version: 5.15.0-161-generic
 Operating System: Ubuntu 22.04.5 LTS
 OSType: linux
 Architecture: x86_64
 CPUs: 2
 Total Memory: 2.407GiB
 Name: please-help-me
 ID: 398f33a7-2b49-4235-bcb9-4e1723a7bd81
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Experimental: false
 Insecure Registries:
  ::1/128
  127.0.0.0/8
 Live Restore Enabled: false
 Firewall Backend: iptables

Quelqu’un peut-il aider ?

Je peux confirmer ce comportement sur au moins deux sites que j’ai configurés récemment. Quelque chose ne va pas avec git.docker.com et il échoue à charger overlay2 par défaut comme il le faisait depuis des années.

Créez /etc/docker/daemon.json avec ce contenu :

{
  "storage-driver": "overlay2"
}

puis

sudo systemctl restart docker

Cela devrait fonctionner après cela.

1 « J'aime »

Moi aussi…

Je veux dire, actuellement, quelque chose ne va pas dans le processus d’installation officiel de Discourse.

J’ai essayé DigitalOcean avec l’installation officielle mais ce message d’erreur apparaît. Ensuite, je suis passé à un autre fournisseur de VPS, même chose.

J’espère que quiconque a des difficultés avec une nouvelle installation de Discourse en ce mois de novembre 2025 :sweat_smile:, trouvera la solution ci-dessus :index_pointing_up:

C’est mon troisième jour à lutter :tired_face: et c’est terminé.

Merci beaucoup Monsieur Jay :folded_hands:

Eh bien, c’est la faute de Docker. Je continue de penser qu’ils vont le corriger, mais jusqu’à ce que je remarque qu’ils l’ont fait, toutes mes installations créent ce fichier pour que je n’aie pas à m’en soucier.

Je m’en suis plaint ici :

1 « J'aime »

Docker utilise un nouveau pilote de stockage par défaut pour la v29.0+

Docker Engine 29.0 et versions ultérieures utilisent par défaut l’espace de stockage d’images containerd pour les nouvelles installations. L’espace de stockage d’images containerd utilise des snapshotters au lieu des pilotes de stockage classiques décrits sur cette page. Si vous effectuez une nouvelle installation de Docker Engine 29.0 ou version ultérieure, ou si vous avez migré vers l’espace de stockage d’images containerd, cette page fournit des informations générales sur le fonctionnement des couches d’images, mais les détails d’implémentation diffèrent. Pour plus d’informations sur l’espace de stockage d’images containerd, consultez espace de stockage d’images containerd.

1 « J'aime »

Donc, si je comprends bien, nous devons également rechercher et inclure overlayfs ?

PR pour cela ici :

1 « J'aime »

Je ne sais pas. Je n’ai pas testé si la superposition fonctionnerait. À un moment donné, cela ne fonctionnait pas, et c’est pourquoi c’est une exigence. Il ne m’est pas venu à l’esprit que ce n’était plus une exigence.

Oh.

Le magasin d’images containerd semble se signaler comme overlayfs, nous devrions donc autoriser également cette chaîne.

Oui, à partir de la publication que vous avez partagée, voici la différence :

<  Storage Driver: overlay2
<   Backing Filesystem: xfs

<   Supports d_type: true
<   Using metacopy: false
<   Native Overlay Diff: true
<   userxattr: false
---
>  Storage Driver: overlayfs
>   driver-type: io.containerd.snapshotter.v1

J’ai également réinstallé/mis à jour Docker sur ma machine de développement, rencontré le même problème, et je peux confirmer que cela semble fonctionner.

3 « J'aime »

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.