Aqua

Last (but not least??) twist : si une copie /upload / déplacement de fichiers vers ce dossier S3 échoue à se terminer alors un paquet de données sont réellement copiées (visibles dans le dossier local et cryptées sur le montage s3fs distant) mais la fonction External Storage de Nextcloud ne scan pas / ne rafraîchit pas le dossier et ces données n'apparaissent pas. il faut faire un occ files:scan %username --path=/path/to/folder pour que ce qui a été copié (rappel, si la copie a échoué tout n'a peut-être pas été copié) apparaisse. Alors que si on fait un upload simple (typiquement de qques mégas) alors le fichier apparait bien dans Nextcloud Files.

Helloooooo Long time no see! Bon après avoir laissé ce "sujet" sur le côté pour faire des choses plus utiles de ma vie (non, en vrai j'ai joué à Enshrouded), j'ai enfin réussi à faire lire ce dossier /mnt/s3next à Nextcloud. Comme Nextcloud AIO a déjà tout prévu, il avait déjà accès à /mnt et je me tapais la tête contre un mur à pas comprendre pourquoi du coup il arrivait pas à voir quoi que ce soit dans /mnt/s3next. Il se trouve, que c'est juste une option fstab à la noix qui était responsable de ça: j'ai juste rajouté "allow_other" à la ligne fstab qui va bien, redémarré le conteneur docker et hourrah ça marche. le conteneur Nextcloud voit maintenant le contenu du dossier, je peux y créer des sous-dossier comme si un s3 était un vrai système de fichier et, comme je voulais faire initialement, je suis capable de donner en tant que External Storage dans Nextcloud des dossier de sauvegarde S3 next.ink tout bien protégé à mes utilisateur.ices \o/ La performance est incertaine pour l'instant. J'ai eu l'impression au début que ça se comptait en kbp/s mais là ça a l'air mieux (sur une connexion fibre domestique) Merci @next merci @bingo.crepuscule !

Bonjour :) J'ai laissé traîner quelques semaines avant de me retaper la tête sur un certain nombre de murs 🤯 Du coup au final merci pour tout :) et voici quelques commentaires (sur la base du 3ème post de ce thread) : BUCKET="lisez-next"C'est le nom du bucket que j'ai. je sais pas si tout le monde a le même mais je suppose que oui. La création du fichier .passwd-s3fs donne un caractère final qui a l'air de pas passer. J'ai du l'éditer pour rajouter un retour chariot. Comme j'avais changé les points de montage du coup le nom des Unit .mount dans le service systemd était plus bon --> mnt à la place de media (pas certain de comment rendre ça paramétrable) Maintenant j'ai un autre souci... bien que le dossier soit bien monté et que j'ai pu créer des sous-dossiers manuellement, leur donner un propriétaire qui va bien, et bien les chemins créés ne plaisent pas à Nextcloud qui refuse d'y créer un stockage externe. A suivre :)

... me suis un peu avancé. J'arrive à monter le S3 directement avec le module External Storage de Nextcloud, à y pousser des fichiers Par contre le script échoue au moment de monter le s3fs: Le montage lui-même ne dit rien (mais "df" me montre bien qu'il n'est pas monté) et l'appel d'après à "is_s3fs_mount" échoue (avec le message d'erreur qui va bien "Erreur: $MOUNT_CRYPT n'est pas un montage s3fs attendu") . le fichier de mot de passe créé a l'air tout à fait correct. ================================================== CLES S3 ================================================== Cles S3 deja presentes. Les remplacer ? (o/N) : ================================================== MONTAGE S3 ================================================== Erreur: /mnt/s3next_crypt n'est pas un montage s3fs attendu zsh: exit 1 ./s3next_install.sh je regarde demain un peu plus en détaille ce que fait la commande de montage et pourquoi elle foire.

Et je viens d'arriver et c'est exactement ce que je cherchais. Un moyen de monter ce S3 localement avec une couche de crypto. Maintenant je vais pouvoir y créer des dossier qui seront autant d'External Storage pour mes utilisateur.ices Nextcloud. Un petit backup externe pour tout le monde \o/ Merci Next, Merci Bingo !