Reprise du message précédent :
Pas forcément, tu peux le monter sur ton hôte docker, et ensuite tu le mappes sur ton conteneur.

Oui c'était l'idée que j'avais en tête, de monter sur l'hôte et partager avec les conteneurs ensuite

Pour mes trucs persos, je préfère monter les volumes NFS/SSHFS depuis docker-compose, ça évite de faire 2 fois le boulot (OS et container).
 

Bon, j'ai progressé, j'ai suivi vos conseils et cette méthode  :  
 
https://help.nextcloud.com/t/change [...] cker/46408
 

 
Je me trouve coincé à un point précis, c'est un volume NTFS et la gestion des droits est faussée, tous les fichiers sont en root:root, chown ne fonctionne pas à cause de ça. Or je dois attribuer tous les fichiers à www-data:www-data  
 
Visiblement il y a une méthode pour résoudre ça, il faut refaire le montage du volume (sur l'hôte docker donc) en ajoutant des petites choses. Entre autre ça parle de UserMapping  (sudo mv UserMapping /mnt/windows/.NTFS-3G/ )
 
Cf ce que j'ai trouvé ici : https://askubuntu.com/questions/118 [...] 4851#74851
 
Sauf que ce n'est pas aussi simple. En fait sur mon host proxmox j'ai un disque dur qui est formaté en "linux file system" (c'est ce qui est écrit). Je partage ce disque à mes VM et à mes utilisateurs windows via un partage SMB. Du coup je ne sais pas comment contourner ce problème de limitation de chown , je ne peux pas utiliser usermap, qui est réservé à un vrai volume NTFS.
 
J'ai toutefois peut être une autre approche, au moment de monter le volume sur la VM docker :  
 
"An alternative is to specify the user and group ID that the mounted network share should used, this would allow that particular user and potentially group to write to the share. Add the following options to your mount: uid=<user>,gid=<group> and replace <user> and <group> respectively by your own user and default group, which you can find automatically with the id command."
 
Voir ici : https://unix.stackexchange.com/ques [...] -and-chown
 
Vous en pensez quoi? En gros il faudrait que je monte un volume spécial pour nextcloud avec comme user/groupe www-data  
 

Bordel c'est si compliqué à installer nextcloud via Docker?

Bah nextcloud via docker c'est un fichier docker-compose tout bête :  
 
https://github.com/nextcloud/docker [...] ompose.yml
 
Par contre ma VM docker elle n'a pas la fonction de stockage, c'est mon host proxmox qui l'a, avec son disque de 4To dont j'ai besoin pour mes utilisateurs nextcloud... J'ai mis à jour mon message juste après ton message, d'ailleurs. C'est encore plus compliqué du coup

 
Je fais pareil, je vois pas le soucis.
Ta VM monte ton stockage proxmox en nfs.
Tu consomme ton point de montage avec un volume docker local

Bah vas-y, fais un chown toto:toto sur le moindre dossier de ton stockage NFS depuis ta machine docker, qu'on rigole. nextcloud ne semble pas pouvoir fonctionner si l'utilisateur www-data n'est pas propriétaire de son arborescence de fichiers.

 
Si tu veux je sais utiliser mes outils    
Tu sais que tu peux faire un bind des users dans un montage nfs... bref chez moi ça fonctionne très bien depuis des années

Pour ton bien, ne joue pas avec le chown en faite. C’est pas spécifique à Nextcloud, tu aurai des soucis avec n’importe quel server web à faire ça

EDIT : à première vue ça a finit par fonctionner, il a fallu que je fasse un "docker container rm blah" pour qu'il reparte sur une base neuve.
EDIT 2 : ensuite j'ai eu des messages d'erreur de droits sur la page web, qui m'ont amené à des gens qui ont également monté du NFS, j'ai fini par trouver la bonne syntaxe grâce à ces messages.
 
https://help.nextcloud.com/t/first- [...] nd/45590/4
 

Bon,  il me reste un souci. L'appli fonctionne, mais pas moyen de me connecter avec les clients android, windows, etc.
 
En gros je rentre login/mdp, ensuite il y a une fenêtre "Autoriser l'accès", et quand je clique ça tourne en boucle sans limite de durée. Alors j'ai l'impression de voir un problème de rebond infini http/https ou autre réjouissance liée au proxy, mais je ne trouve rien dans aucun log pour le confirmer. J'en suis à me demander si je ne devrais pas ressortir mon vieux wireshark...
 
J'utilise Traefik pour gérer la partie reverse proxy + https.

Allez je suis sympa:
Je dirais qu'il te manque ça dans ton config.php
 
'overwrite.cli.url' => 'https://ndm.fr',
  'overwritehost' => 'ndm.fr',
  'overwriteprotocol' => 'https',

Je les ai déjà renseignés
Merci pour votre aide à tous en tout cas.

Regardes les logs Traefik. Ta résolution DNS

Dans la création de ton conteneur, tu ouvres bien les ports de next cloud? ( Option -p de mémoire)

Pas besoin d'exposer les ports avec un reverse proxy comme Traefik, qui accède au container via un réseau Docker.

Ah oui c'est vrai
Donc là question c'est si les 2 conteneurs sont sur le même network?

Oui

J'avais rien eu à faire de particulier pour faire fonctionner Nextcloud (y compris avec les applis Android) derrière Traefik 2.x :
 

Dans config/config.php :
 

Fredouye merci pour ton partage.
Je viens d'aligner mon docker-compose avec le tien, ça ne résout pas le souci... (config/config.php était déjà ok)
 
 
EDIT : je viens de résoudre le problème, il faut ces lignes dans le config.php
 

 
C'est en ajoutant celles en rouge que ça s'est mis à fonctionner....

Bon, j'ai posé une question sur le topic proxmox mais j'ai l'impression que c'est ici que j'aurais dû la poser. Plus haut j'ai dit que j'ai créé un volume NFS qui est ensuite utilisé dans Docker :  
 
docker volume create -d local-persist -o mountpoint=/data/nextcloud-data --name=nextcloud-data
 
En fait ça ne fonctionne pas bien. Dans l'appli j'ai 7mbps de transfert et une grosse latence à chaque accès, ainsi qu'une montée du CPU. Du coup je me demande si je ne devrais pas plutôt passer par la méthode préco par docker :  
 
https://docs.docker.com/storage/volumes/
 
NFSv3

 
NFSv4

 
Le problème c'est que je ne sais pas comment régler les problèmes de propriétaire de fichier que j'avais réglés avec la commande suivante :  
 

un jour tu comprendras que les balises fixed sont faites pour empêcher le formatage du contenu...

Donc initialement je tournais avec ce montage :  
 
docker volume create -d local-persist -o mountpoint=/data/nextcloud-data --name=nextcloud-data  
 
Dans le doute j'ai suivi la préco docker, à savoir créer un volume nfs en tapant directement sur le serveur samba :
 
docker volume create --driver local --opt type=nfs --opt o=addr=192.168.1.25,rw --opt device=partage/Cloud nexycloud
 
Bah même résultat   .

C'est encore moi. J'ai résolu le problème de performance, je ne sais pas trop comment mais maintenant c'est bon. Par contre j'ai fait un dernier changement dans mon docker-compose et je ne comprends pas ce qui cloche.
 
AVANT :
 
[...]
app:
    image: nextcloud
    restart: unless-stopped
    ports:
      - 8070:80
   volumes:
     - pointMontage1: /var/www/html
[...]
volumes:
  pointMontage1:
          external: true
 
 
APRES :
 
[...]
 app:
    image: nextcloud
    restart: unless-stopped
    ports:
      - 8070:80
    volumes:
      - ./wwwhtml: /var/data/www/html
      - pointMontage1: /var/data
 
[...]
volumes:
  pointMontage1:
          external: true
 
 
 
En gros ce que j'ai changé, c'est que le répertoire www/html (donc tout le source nextcloud) était sur mon point de montage, donc mon HDD, et j'ai changé pour mettre www/html en binding local d'une part, et les données www/html/data sur mon point de montage. D'autres l'ont fait dans les forums.  
 
Mon problème, c'est que docker ne tient plus compte de ces mappings. En gros quand je démarre le conteneur, que ce soit avec un up ou un restart, il me met l'écran de première connexion de nextcloud. Et quand je me rends dans le conteneur avec un "docker exec -u root -it" , je vois clairement qu'il utilise une arborescence de fichiers 100% vierge qui ne coïncide pas avec le mapping " ./wwwhtml: /var/data/www/html".  
 
Je ne trouve pas comment  faire appliquer le binding de volumes. J'ai tout essayé, j'ai même essayé "docker-compose rm mon_app", mais ça ne  fonctionne pas. Et ceci semble confirmer que j'ai un souci dans le mapping des volumes :
 

Ca ne semble pas très logique de monter '/var/data/www/html' puis '/var/data'...

Merci, c'était ce "data" de trop qui traînait.

#NOOB
 
Hello,
Je suis sur un laptop sous W10Pro et j'ai installé docker puis créé péniblement un conteneur linux basé sur Oracle : store/oracle/database-enterprise:12.2.0.1-slim
 
Hier, je démarre mon conteneur et crée un utilisateur puis une table dans la base par défaut contenue dans le conteneur pour tester. Depuis mon poste, je peux me connecter à la base (mappé les ports 8080 et 1521). Super !
J'ai stoppé mon conteneur, relancé et constaté que mon utilisateur est toujours présent. Je me suis dit chouette, je vais pouvoir abandonner ma VM qui consomme un place folle sur un HDD externe et bouffe un max de RAM... Sans compter que cette VM ne cesse de grossir au rythme des dumps remontés dedans.
 
Cet après midi, après avoir rallumé mon PC et relancé le conteneur, l'utilisateur Oracle créé à disparu. J'ai l'impression que le conteneur a été RAZ...
 
Que faut-il faire pour faire persister les données, et ce même après l'extinction de mon PC ? Comme dans une VM quoi
J'ai tenté l'option -v C:\oradataORCL mais ça m'a recopié tout le contenu du répertoire /ORCL du conteneur  en local dans C:\oradata. J'imagine que cela occupe 2 fois plus de place du coup...
Par contre, j'ai créé en local un fichier C:\oradata\test.txt que je vois dans le conteneur quand le fait un "ls /ORCL/*". C’est peut être la solution ?
 
En tout cas, c'est super comme techno, on peu faire mumuse indéfiniment le temps d'obtenir un master bien clean...

A priori ça marche !
Quand j'ajoute un fichier dans C:\oradata je le vois dans le conteneur et vice versa
J'ai créé un utilisateur et importé un dump et même aprés avoir arrêté et redémarré le PC mes modifs persistent.

Par contre, le PC est au taquet, toute la RAM physique est utilisée.

Tu as combien de ram en tout? Tu as activé l'interface graphique sur linux?

J’ai 8Go et pas de serveur x qui tourne, tout en ligne de commande.
Le processus Windows en charge de l’émulation prend 2Go de RAM à peu près.

Bon, moi j'ai une question de noob, encore. J'essaie de mettre à jour home assistant qui est configuré via docker-compose.
Avant tout manip, j'ai fait un backup de mon conteneur, et j'ai fait un docker ps qui donnait ça :  
 
c0e6984b7c3b        homeassistant/home-assistant:stable   "/bin/entry.sh pytho…"   11 months ago       Up 58 minutes (healthy)              hass
 
Ensuite  
 
docker pull homeassistant/home-assistant:stable
Status: Downloaded newer image for homeassistant/home-assistant:stable
docker.io/homeassistant/home-assistant:stable
 
Ensuite  
docker ps
c0e6984b7c3b        6d93015a27be                       "/bin/entry.sh pytho…"   11 months ago       Up About an hour (healthy)            hass
 
Déjà là je ne comprends pas pourquoi mon conteneur a perdu son nom.
 
Ensuite je fais  
 
docker-compose restart
 
Bilan : j'ai toujours la même version de docker de 2019 : 0.102.3  / Version interface utilisateur : 20191119.6 - latest
Est-ce que c'est parce qu'ils n'ont pas publié de nouvelle version stable?
 
 
EDIT : ok, fallait faire un "docker rm mon_conteneur_id"

Concernant le nom du container, est-ce que tu le forces ?
 

 
Ca ne semble pas étonnant que ta version de Home Assistant n'ait pas changé, ton image date toujours d'il y a 11 mois
 
Ca te donne quoi ceci ?
 

Ton conteneur n'a pas perdu son nom. Il s'appelait hass, il s'appelle toujours hass.

Par contre en mettant à jour l'image, l'image utilisée par ton conteneur a perdu son "tag".
Avant : homeassistant/home-assistant:stable => 6d93015a27be
Après le pull : homeassistant/home-assistant:stable => un_autre_hash

Du coup le docker ps t'affiche l'id de l'image, puisqu'elle n'a plus de lien avec le nom homeassistant/home-assistant:stable

Rien d'anormal, un même tag ne peut pas pointer sur 2 images différentes, sinon vla l'incertitude quand tu lance un conteneur.

Plutot que de faire un rm puis un start, tu peux demander à docker-compose de mettre à jour ton service (il va détecter que l'image de ton conteneur n'est pas à jour par rapport à ce qui est dispo localement) :

Hello,
Dites, j'ai un petit soucis avec Portainer sur mon Synology :

 
Je me suis rendu compte que son conteneur n'était pas redémarré car j'avais déplacer son dossier monté : j'avais un dossier portainer-ce et j'ai déplacé le dossier portainer dans un dossier backup...
Bref, j'ai remis le dossier portainer au bon endroit, viré le dossier portainer-ce qui ne servait en fait a rien...
Puis j'ai relancé mon conteneur avec un docker-compose up -d, c'est reparti sans erreur.
Voilà mon fichier docker-compose.yml

 
Pourquoi il n'arrive plus à se connecter sur le socket ?
Qu'est-ce que je dois faire pour rectifier le tire ?
Merci d'avance

Bon bah après avoir fait ceci :

 
Ca refonctionne :

 
J'ai profité pour passer le restart en always.

unless-stopped >> always

+1
Et j'étais avant partisan du always, jusqu'au jour où je n'ai pas compris pourquoi mon service était pas dispo alors que mon container tournait. En regardant les logs, il se cassait la gueule toujours au même endroit

Du coup vous préconisez quoi ? De laisser en Unless-Stopped ?

Oui.
Ça t'indiquera mieux visuellement que quelque chose cloche dans ton container.

Ok je rechange alors ^^
 
edit : bah en fait j'avais pas changé le paramètre... je suis toujours en unless-stopped