Reprise du message précédent :
Petite question qui n'a rien à voir, mais ayant vu nono87410 parler de rsync, je me demande si c'est bien l'outil qu'il me faut.
 
Ce que je voudrais, c'est une fois mon RAID5 principal monté, faire une sauvegarde d'un ou plusieurs dossiers donnés vers soit un autre disque dur, soit une clef usb. Comme ça, en plus de mon RAID5, toutes mes photos / vidéos souvenirs ainsi que documents de boulot et autre seront constamment à l’abri.
 
Est-ce bien ce que fait rsync? Si oui, est-ce qu'il fait la vérification périodiquement (genre ça vérifie une fois par jour, semaine, mois qu'il y a un changement et sauvegarde ces changements) ou en direct (dès qu'il y a une modification faîte, ça le fait automatiquement).
 
Désolé si ça semble être une question idiote, quand j'utilisais un NAS, ma seule utilisation c'était mettre mes fichiers dispo en réseau local et client torrent.

 
 
Oui C'est exactement le but de rsync de faire de la redondance de données sur un autre support (local ou distant ) en automatique , après je ne sais pas si c'est la meilleur solution pour faire de la sauvegarde de donnés , mais moi comme j ai  
un Nas en raid 5 de 5,5 To je vais acheter  un gros disque externe et  je vais le brancher en usb  directement sur mon routeur Netgear et faire des rsync des dossiers les plus importants pour moi.

Quand on fait une "sauvegarde", en général on fait ça vers un disque dur plus gros, et on fait de l'incrémentiel pour avoir un historique.  
 
Tu peux faire "juste" de la synchro mais ça veut dire que tout ce qui est supprimé sur ton espace est supprimé de la synchro.

 
Pas forcement tu as des options avec rsync pour ne pas effacer les fichiers ou les dossiers  existant la ou tu copie meme si tu les as viré sur l'origine

Oui, effectivement c'est bien l'outil qui te faut. Rsync travaille avec un système de fichiers (ext4 par exemple) et en a rien à secouer de comment est ta redondance de données (RAID0/1/5/6/10, JBOD).
Rsync peut être couplé (et je te le recommande vivement!) à des cron jobs. Ce sont ces derniers qui vont faire ta vérification périodique, au préalable définit (pas de watching folder donc).
Je te conseille aussi de te pencher sur le système de fichiers que tu vas mettre en place sur ta clef USB: Est-ce qu'elle sera lu que dans un environement linux? --> ext4 Est-ce que tu dois pouvoir la lire sur d'autres OS (Windows, Mac)? --> FAT32
 
EDIT: Bourdel, il y a du monde qui est passé entre temps

Et pourquoi pas directement en USB au cul de ton NAS?

 
oui aussi c'est juste que c'est plus pratique pour moi mon Nas est au sous sol et mon Netgear en haut dans la maison        
Bon ce matin le nas renvois ça, et je n ai plus aucun container dans docker c est vide donc je n ai plus aucun soft qui fonctione      
 

 
 
 

Mais tu vas saturer le réseau pour rien Pendant la nuit pourquoi pas.
 
Je te conseille vivement de faire une sauvegarde au plus vite de tes docs les plus important. Clairement un de tes disques est entrain de rentre l'âme. Si mdadm n'a pas voulu le monter sans forçage, elle est la la raison.  
 
Concernant Docker, tu ne stockais pas tes images/config sur ton SSD?

 
Concernant Docker, tu ne stockais pas tes images/config sur ton SSD?[/quotemsg]
 
Non ça c est un truc que je comprend pas je n ai pas accès a mon ssd depuis mes partages sur openmediavault j'ai juste mon system dessus

Tu peux lancer:

• docker info
• docker images
• docker ps

Merci pour les réponses les gens, bon on dirait bien que c'est ce qu'il me faut

Pas de problème avec ça. Vu que c'est du dossier souvenirs + documents du taf, je ferai qu'ajouter des trucs dedans et les rares trucs que je supprimerai seront en général des photos doublons ou ce genre de cochonneries quand je ferai mon tri périodique de mes données

Le machin étant prévu pour constamment être branché sur le NAS, ce sera surement du ext4, même si pouvoir le brancher sur du windows aurait été cool. Le problème avec le fat32, c'est qu'il y a des chances que le disque fasse plus de 2to et qu'il y ait des fichiers de boulots de plus de 4 go

Je sais pas pourquoi je me suis mis en tête que tu voulais utiliser une clef USB
Si tu veux avoir une compatibilité avec Windows, il faut que ton media externe soit formaté en NTFS et que tu installes le paquet ntfs-3g. Au prix de performances plus dégradées, ce qui pourrait quand même suffire pour de la sauvegarde.
 

Je sais, mais tu n'as pas d'historique des modifications.
un fichier modifié est remplacés.

Donc prenons le cas extrêmes d'un cryptolocker, ben t'as plus rien, le rsync ayant tout remplacé.
D'ou l'intéret des sauvegardes incrémentale

Il vaut mieux du borg backup ou autre outil du style ou tu gardes X versions/jours.

Peut-être parce que j'ai cité une clef usb dans les solutions possibles Mais bon, vu que j'ai des HDD de 250 go qui trainent dans les cartons à matos divers, ça sera toujours moins cher de les utiliser que d'acheter une clef usb de même capacité

Je pense que je vais me rabattre sur ext4, pas envie de solution bidouillée Au pire tant pis, si la machine tombe en rade et que je dois récupérer les données, je le ferai sur un distro

Je comprends la théorie, mais est-ce utile dans la pratique pour un usage personnel? Je veux dire par là que ça doit prendre pas mal de place non? Parce que là, je dois avoir 200 Go de trucs à "sauvegarder". Avec un bête rsync, je peux le faire sur 1-2 disque pour les 5 prochaines années facilement. Avec les une sauvegarde incrémentale, ça doit prendre quoi, facilement le double non?

rsync fait pas de l'incrémental avec –link-dest?
 

Ou un LiveCD suffit amplement

Sauf que si entre temps rsync copie tes fichiers vérolés par le crytolocker, la sauvegarde te fait une belle jambe
 
 

Faut regarder, jamais utilisé cette option.
 
 
 

ça dépend ce que tu fais. Si tu modifies 200go de donnée, oui tu as forcément 200go en plus.
Mais si tu modifies des petits fichiers est ce ne sont que quelques ko qui sont en doubles.  
 
De plus borg gère la déduplication, donc si une donnée est présente à deux endroits ça compressera en même temps donc c'est pas forcément dit.
Mais en général oui il faut un stockage plus grand que la source là ou tu veux sauvegarder.  
Si tu fais un rsync manuel vers des disques dur et que tu fais des rotations, alors tu auras cet historique  d'une certaine manière.

 
Concernant Docker, tu ne stockais pas tes images/config sur ton SSD?[/quotemsg]
 
Tu ma mis la puce a l oreille la, est ce qu'il est possible d'avoir accès au disque system depuis les partages d'OMV .
Je m'explique  aujourd'hui j ai un disque SSD de 120 Go ou dessus je n'est que le system d'installé, ça veut dire que sur ce disque il y a quelque chose comme  
110Go qui ne servent jamais comment est ce que je peu palier à cela , est ce qu'il faut partitionner le disque avant l' install d' OMV ?
 
Bon sinon pour mon problème docker c'est bon c'est résolu un problème de droit sur le dossier Docker, je suis entrain de copier mon raid 5 sur un gros disque que j ai acheté .
 
j'ai essayé de me servir de borg-backup mais j'ai plein d'erreurs et je n'ai pas franchement tout compris, il faut que je me penche sur la question , donc pour l instant je copie en directe via ssh ,je pense que le system a eut un soucis et il y a un problème de stabilité donc j'attend la fin de la copie (25h00) et je réinstalle tout en propre. d'ou ma question sur un éventuelle partitionnement de mon SSD      

Bonjour,
 
J'aimerai une confirmation pour une stratégie de migration de storage sur une de mes instances OMV5 (VM).
 
Actuellement, j'ai un R5 + spare de 4+1 HDD 2To (omv1:raid5):
 

 
Je n'ai qu'un seul filesystem qui utilise l'intégralité du R5 (raid5ext4):
 

 
Et plusieurs shares définis sur ce FS avec un certain nombre de services actifs pour chaque share:
 

 
Maintenant, je compte remplacer ces HDDs en R5 par 2x4To SSD en single avec un FS sur chaque en suivant cette "procédure":
 
1.- Attacher les 2 SSD à la VM en passthrough.
2.- Créer un FS sur chaque SSD (ssd1ext4, ssd2ext4).
3.- Faire des copies via RSYNC des différents shares de raid5ext4 sur ssdXext4.
4.- Stopper les services
5.- Editer chaque shares en replaçant le device raid5ext4 par le ssdXext4 correspondant.
6.- Démarrer les services
7.- Tester les clients
8.- Umount + delete raid5ext4
9.- Delete omv1:raid5
10.- Reboot VM en masquant les HDD.
 
Ca vous semble correct ?

Absolument.
Tu ne mets pas les SSD en RAID ?

Non, je ferai une synchro planifiée "temps réel" entre mes deux NAS localement et une autre hebdomadaire dans le cloud.

 
Plusieurs solutions :  

• soit installer debian (et donc partionner ton disque) puis installer les paquets omv.
• soit utiliser le plugin sharerootfs dans omv-extras, qui permet de créer des dossiers partagés sur le disque racine.

Bonjour à tous.
 
Je sollicite votre aide car j’ai du mal à installer correctement Nextcloud sur mon installation OpenMediaVault 5.
 
Je suis un grand débutant en linux, docker et nextcloud.
 
J’ai tout de même, à force de persévérance, réussi à installer mon serveur plex en docker sur ce même omv5, qui fonctionne parfaitement avec accès distant et plexpass, donc j’ai quelques bases.
 
 
Pouvez-vous m’aider à configurer correctement mon fichier STACK ?
 
Je souhaite accéder à mon Nexcloud directement par
http://mon-ip-locale OU http://mon-ip-wan
Je n’ai pas besoin d’y attacher un nom de domaine, je n’utilise pas de serveur dns personnel type nginx.
 
J’ai mis en rouge les champs que je ne sais pas renseigner correctement, merci.
 
---
version: "2"
services:
  nextcloud:
    image: linuxserver/nextcloud
    container_name: nextcloud
    environment:
      - PUID=1002
      - PGID=100
      - TZ=Europe/Paris
    volumes:
      - /srv/dev-disk-by-uuid-2d85bf44-b02a-444f-93af-18dd6bcf0ebe/AppData/Nextcloud/config:/config
      - /srv/dev-disk-by-uuid-2d85bf44-b02a-444f-93af-18dd6bcf0ebe/nextcloud/data:/data
    ports:
      - 443:443
    depends_on:
      - mariadb
    restart: unless-stopped
  mariadb:
    image: linuxserver/mariadb
    container_name: nextclouddb
    environment:
      - PUID=1002
      - PGID=100
   - MYSQL_ROOT_PASSWORD= n’importe quel password ?
     - TZ=Europe/Paris
   volumes:
      - /srv/dev-disk-by-uuid-2d85bf44-b02a-444f-93af-18dd6bcf0ebe/AppData/Nextclouddb:/config
    restart: unless-stopped
  swag:
    image: linuxserver/swag
    container_name: swag
    cap_add:
      - NET_ADMIN
    environment:
      - PUID=1002
      - PGID=100
      - TZ=Europe/Paris
      - URL= ?????
      - SUBDOMAINS= ??????
      - VALIDATION=http
      - EMAIL= ??????
 
    volumes:
      - /srv/dev-disk-by-uuid-2d85bf44-b02a-444f-93af-18dd6bcf0ebe/AppData/swag:/config
   ports:
      - 444:443
      - 81:80
    restart: unless-stopped
 
_-_-_-__-_-_-_-_-_-_-_-_-__-_-_-_-__-_-_-__-_-_-_-_-_-_-_-_-__-_-_-_-_
 
 
Pour Info:
 
- Le matériel:
Beelink GK55 + SSD 2TO crucial MX500
http://www.bee-link.com/portal.php [...] ew&aid=144
 
- OS:
OpenMediaVault 5.5.23-1 (usul)
 
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-__-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 
Mon réglage réseau:
 
1. SFR box nb6 (fai red by sfr / 192.168.1.1) >
   .redirection des ports vers mon routeur «archer c-7 tp-link» (192.168.1.2/192.168.0.1)
 
https://zupimages.net/up/21/03/w69k.png
 
 
2. redirection vers mon NAS Beelink (192.168.0.42)
https://zupimages.net/up/21/03/zw0b.jpg
https://zupimages.net/up/21/03/8e35.jpg
 
> J’utilise ces réglages pour afficher sur les ports 80 et 443 mon Jeedom de mon raspberryPi3 (192.168.0.3) sans problèmes, idem pour d’autres services de mon synology, et pour le port 32400 de Plex sur ce meme serveur OMV5, sans problèmes.
Pour l'instant, au lieu d'afficher mon jeedom sur mon rpi3 sur les ports 80 et 443, j'afficherais nextcloud.
 
_-_-_-__-_-_-_-_-_-_-_-_-__-_-_-_-__-_-_-__-_-_-_-_-_-_-_-_-__-_-_-_
 
J’ai suivi ce tuto:
https://pled.fr/?p=16959
 
Après un 1er essai , je fini par avoir NextCloud qui fonctionne en local, mais il a fallu que j’écrive manuellement le https dans l’adresse, et le navigateur m’informait que le serveur n’était pas sur, et impossible d’avoir l’accès depuis l’extérieur…
 
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-__-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
 
MERCI INFINIMENT DE VOTRE AIDE !!!!!!!!!!!!!!!!!!!!

nginx n'est pas un "serveur" dns, c'est un serveur web (http) qui fait aussi reverse proxy.
 
Et pour infos ton container swag, c'est justement ça.
 
Ensuite tu ne veux pas de nom de domaine ou sou-domaine. Le problème c'est que swag est fait pour générer un certificat signé via les services de letsencrypt, et pour cela il faut une validation, qui se fait par nom de domaine, et pas par ip.
 
Une  solution serait de générer un certificat auto-signé pour ton adresse ip. Mais il ne sera pas considéré "de confiance" par un navigateur web. Tu auras donc les messages d'avertissement également.
 
L'autre solution est de finalement utiliser un sous domaine, qu'un service de dns dynamique comme duckdns peux te fournir.
Il te faudra rajouter dans ta stack un container duckdns pour mettre à jour régulièrement le dns. Il te faudra également configurer swag correctement (tu peux aller voir ici : https://docs.linuxserver.io/general [...] dcard-cert, l'article entier est une mine d'informations pour configurer le container comme il faut, notamment la partie reverse proxy.)
 
Concernant ta config réseau, tu rediriges d'abord vers ton routeur (192.168.0.2), puis ton routeur redirige lui même vers le serveur OMV5 (192.168.0.42) ?
Quelque précision, tu ne peux pas avoir de multiple service écoutant le même port, donc veille à changer les ports de ton jeedom pour libérer ton 443 (et 80 si besoin, mais vu que c'est pas safe, j'éviterais de le montrer à l'extérieur).
Aussi dans ton fichiers stack, tu publie 2 fois le port 443.
 
 
 
 
 
 
 

 
Merci beaucoup pour ta réponse.
Je vais m'enregistrer sur DuckDNS.
 

C'est exactement ca, je ne peux pas me passer de la box de red pour le telephone fixe, sinon je n'aurais que le routeur tp-link.
 

J'ai enlever les redirection de la box red et mon tp-link pour tout redirigé vers l'ip du nas et plus du rpi qui héberge jeedom, ca devrais suffire je pense.
 

Oui, une fois pour Nextcloud en ligne 14 (443:443), et une fois pour stack a la fin, en ligne 45 (444:443).
Le tuto suivi était comme ca, je ne sais pas comment rectifier correctement ...    
 
 
Merci de ton aide.

Salut,
 
Comme je suis en phase de reconfiguration du storage de mes deux NAS OMV5 (VMs) j'aimerai en profiter pour encrypter les disques ou les volumes.
 
Quelle serait l'approche la plus simple ? Idéalement j'aimerai que la clé soit fournie au boot via un serveur NFS ou HTTP qui serait situé sur un RPI en PoE quelque part dans la maison. Donc toujours disponible en cas de reboot @home mais qui rendrait le unlock impossible en cas de vol des NAS.
 
Merci

 
Je m'étais déjà penché sur la question pendant les dernières vacances. J'avais trouvé une piste plutôt intéressante, en fetchant la clef LUCKS et déverrouillant le volume ext4 dans un service qui attend que le réseau soit initialisé. Je ne suis pas allé au bout car je n'avais juste pas chiffré mon volume  
 
Si tu utilises des VMs, tu peux peut-être aussi voir au niveau de l'hyperviseur.

Bah non si c'est l'hyperviseur qui fournit la clé, si on me vole mon serveur, donc la VM et son HV le NAS démarrera normalement avec ses volumes unlocked...

Non, je te parlais du chiffrement Sinon on est d'accord, ça n'a pas de sens

Tiens autre question, vu que je change de storage autant passer en btrfs ou bien rester en ext4 ?

J'ai réussi à faire un LAB fonctionnel avec un disque crypté LUKS qui se débloque au boot si un fichier est présent via NFS sur un RPI \o/

Je le laisse faire ton propre avis en lisant ce très très long post sur github où le main dev veut instaurer btrfs comme FS unique pour OMV 6.
Cependant les "tags" sont passés de "6.x affected" à "6.x planned", ce qui pourrait laisser croire à un abandon de cette fonctionnalité pour la version 6.
Ce qui nous laissent toujours avec cette épée de Damoclès toujours au-dessus de la tête des utilisateurs.

Tu as fais comment?

Je vais rester en ext4 c'est plus sûr. Au moins c'est éprouvé ...
Pour LUKS, je termine mes migrations et je ferai un mini tuto mais y'a rien de bien transcendent

Chiffrer* un disque (DATA pas OS) avec LUKS avec stockage de clé sur un serveur NFS distant
 
Le but est d'avoir l'intégralité des DATA stockées sur mes NAS chiffrées avec une solution permettant de déverrouiller le disque automatiquement lors du boot sans pour autant stocker les clés localement. Ce qui n'aurait d'ailleurs aucun intérêt ...
Mes instances OMV sont des VMs hébergées sous Proxmox avec des disques en pass-through. Ces disques sont donc utilisables sur n'importe quel linux disposant des services nécessaires à l'accès aux fichiers. Donc cette méthode fonctionnera de la même manière sur un OMV "physique".
 
Les clés "fichier" sont stockées sur un serveur NFS, qui dans mon cas est un RPI2 (omv3.home), aussi sous OMV, planqué dans une goulotte et alimenté en PoE, donc la probabilité qu'il soit volé avec les NAS est quasi nulle. Ce RPI partage en NFS (et CIFS mais ça n'a pas d'importance ici) un ext4 basé sur une carte SD de 8Go dans un adaptateur USB-A qui me sert aussi à faire un backup des headers LUKS en cas de corruption de ces derniers, d'où le partage en RW:
 

 
Maintenant sur le NAS (omvtest.home). Il faut savoir que le chiffrement** est à faire AVANT de commencer à stocker des DATA sur le disque, car cette opération détruit le contenu de ce dernier lors de l'initialisation. Donc soit à faire sur un nouveau disque puis copier et déplacer les shared folders ensuite, soit sur une nouvelle installation, soit en faisant un backup des données au préalable puis chiffrement du disque et restauration des données. Dans mon cas j'ai profité du passage de vieux HDD à des SSD pour le faire, donc dans le premiers cas.
 
Il faut d'abord installer le plugin openmediavault-luksencryption qui se trouve lui-même dans le repo OMV-extras (donc à installer/activer avant d'installer le plugin).
 
Ensuite il faut faire un wipe sur le disque à chiffrer (/dev/vdb pour moi):
 

 
Puis chiffrer le disque en le sélectionnant et en choisissant un mot de passe (complexe si possible, je préfère une phrase simple de plusieurs mots qu'un mot de passe impossible à retenir) pour pouvoir faire un déverrouillage manuel:
 

 
Et faire le premier déverrouillage manuellement avec le mot de passe/phrase précédent:
 

 
Il ne reste qu'à créer un nouveau filesystem sur le disque chiffré:
 

 
Le reste est identique à une installation standard, monter le filesystem dans le GUI puis créer un ou plusieurs shared folders puis ajouter les services voulus (NFS, CIFS, ...).
 
Dans cet état, lors d'un (re)boot, le filesystem ne sera pas monté, et donc les shared/services associés non démarrés, tant que le mot de passe de déverrouillage n'aura pas été entré via le GUI OMV ou bien via la commande cryptsetup en CLI.
Pour automatiser le tout, il faut donc créer une clé non-interactive, en utilisant un fichier clé. Ça peut être n'importe quel fichier, une image, un PDF, un binaire, etc, ... Je vais utiliser un fichier de type "data" contenant des données générées aléatoirement. Mais avant ça, il faut monter le partage NFS du RPI car c'est lui qui va fournir les fichiers clé.
 
S'assurer dans un premier temps que le partage est bien accessible depuis le client:

On retrouve bien le /export/usb défini au début sur le RPI (omv3.home).
 
Créer un point de montage sur le NAS, via "mkdir /crypto" dans mon cas. Le montage NFS se fera au boot via un service et sera démonté ensuite une fois le(s) disque(s) déverrouillé(s).
Mais pour générer la clé (et pour valider la configuration NFS entre OMV et le "serveur de clés" ) il faut manuellement monter /crypto:

Il faut à présent créer le fichier clé et l'ajouter comme clé de déverrouillage dans le device LUKS. Avant tout il faut récupérer le nom de ce device et ça se trouve dans le GUI:
 

Le device est donc /dev/mapper/vdb-crypt et on voit qu'il est déverrouillé et qu'actuellement une seule clé est configurée (le mot/phrase entré lors de la création) sur les 32 disponibles.
 
On peut interroger le status avec cryptsetup:

On peut créer à présent un fichier clé de 64bits (je trouve ça amplement suffisant mais vous pouvez faire plus) en utilisant dd et le device urandom. je le nomme (c'est personnel ...) hostname-physname.key:

Une fois le fichier clé créé, on l'ajoute au disque chiffré (donc à /dev/vdb et non à /dev/mapper/vdb-crypt). Le mot/phrase est demandé:

On peut vérifier dans le GUI que le nombre de clés est passé à 2/32.
 
Il faut à présent indiquer à LUKS où trouver cette clé lors du (re)boot pour que de déverrouillage soit automatisé tant que le RPI est présent sur le réseau. Il faut ajouter une ligne dans le fichier /etc/crypttab.
Pour se faire il faut avoir le nom du device déverrouillé (vdb-crypt) ainsi que son UUID du disque physique donné par la commande cryptsetup:

Il ne reste plus qu'à faire en sorte que le déverrouillage lors du (re)boot attende que le montage NFS soit disponible avant d'essayer de déverrouiller. Il faut pour celà ajouter le point de montage /crypto dans la variable CRYPTDISKS_MOUNT du fichier /etc/default/crypdisks:

Dernière étape, ajouter un service qui va démarrer avant OMV qui va s'assurer que le(s) disque(s) est/sont déverrouillé(s).
 
Ajouter le service en créant le fichier /etc/systemd/system/luks-unlock.service contenant:

Créer le script /usr/local/bin/luks-unlock.bash lancé par le service qui va monter le share NFS contenant les clés, déverrouiller le/les disque(s) et démonter le share ensuite avant de passer la main au démarrage d'OMV.

Il faut juste adapter les variables KEYMNT (point de montage du share NFS contenant les clés) et KEYLOC (IP du NFS serveur et partage à monter) suivant votre environnement, et rendre le script exécutable:

Et enfin activer le nouveau service:

Un reboot pour valider que tout fonctionne correctement et voilà
 
Il ne reste qu'à faire un backup (en profitant de /crypto) du header du device LUKS. Le header intègre toutes les clés définies, et en cas de corruption de ce dernier, ça peut arriver, il est possible de restaurer ce dernier avec la commande cryptsetup en indiquant le backup précédent. Donc je conseille de faire un backup après chanque modification (ajout, suppression) de clé dans le device chiffré, que ça soit via le GUI ou via cryptsetup.
 
Backup:

Restore:

 
Voilà
 
* Chiffrer: Procédé permetant de réaliser un chiffrement.
**Chiffrement: C’est un procédé de cryptographie. Le chiffrement permet de rendre incompréhensible un document. Sauf si on possède la clé de (dé)chiffrement.
 
Commandes diverses:
 
Déverrouiller un disque avec passphrase: cryptsetup -v open /dev/vdb vdb-crypt
Déverrouiller un disque avec ficher clé: cryptsetup -v open /dev/vdb vdb-crypt --key-file=/crypto/omvtest-vdb.key
Afficher les infos complètes LUKS: cryptsetup luksDump /dev/vdb

Ce tuto de bon matin Je vais le mettre direct en FP ce soir en rentrant du boulot!
Au final je vois que tu n'es pas passé par un service, j'ai l'impression de m'être fait chié pour rien  
 
Petite question: Est-ce que l'on peut supprimer le mot de passe initial et ne déverrouiller que ton volume LUKS par la clef générée?

Je viens de tester (n'y croyant pas trop) avec un syntaxe logique et oui c'est possible

Sinon j'ai vu hier dans les man pages de crypttab qu'on peut aussi ajouter _netdev dans les options donc luks,_netdev mais je n'ai pas testé. Ca permet d'ajouter une condition sur la disponibilité du fichier clé.

Bonjour,
J'ai monté un nas (ancien pc) sous openmediavault. Après activation des différents protocoles j'ai procédé à des tests.
En invite de commande, échec d'authentification, avec filezilla idem et sous windows mon nas apparaît mais lors de la connexion idem erreur d'authentification. Mon mot de passe est le bon c'est celui qui me sert quand j'accède via le navigateur.
 
Est-ce que j'ai mal configuré openmediavaut car je ne suis pas très bon un conseil me serait bien utile.
merci

Il faut ajouter ton/tes users dans OMV (pour l'accès depuis windows je créé le même user/password c'est plus simple).
Ensuite tu sélectionnes le dossier partagé sur lequel tu veux que le/les users accèdent et dans ACL tu choisis ce que chaque user peut faire (lecture seule, lecture/écriture, pas d'accès).

Tout d'abord merci de m'aider.
Il y avait déjà un utilisateur mais pour reprendre à zéro je l'ai supprimé.
Je viens d'en ajouter un, ça demande une adresse mail faut-il la renseigner et faut-il modifier shell et faut-il l'intégrer dans groupe.

Juste nom et mot de passe, le reste tu laisses comme c'est.

Deadlock, merci
J'ai l'accès depuis windows et j'ai transféré des fichiers sans problème.
Mais toujours le problème avec le protocole ftp. La connexion avec filezilla me remonte les données suivantes:
Statut : Résolution de l'adresse de jeanlucnas
Statut : Connexion à 192.168.1.16:21...
Statut : Connexion établie, attente du message d'accueil...
Statut : Initialisation de TLS...
Statut : Vérification du certificat...
Statut : Connexion TLS établie.
Statut : Connecté
Statut : Récupération du contenu du dossier...
Commande : PWD
Réponse : 257 "/" est le répertoire courant
Commande : TYPE I
Réponse : 200 Type paramétré à I
Commande : PASV
Réponse : 227 Entering Passive Mode (192,168,1,16,223,198).
Commande : LIST
Réponse : 150 Ouverture d'une connexion de données en mode BINARY pour file list
Réponse : 425 Impossible d'établir la connexion de données : Opération non permise
Erreur : Impossible de récupérer le contenu du dossier
Statut : Connexion interrompue par le serveur

C'est plus un problème de permission la. La connexion au serveur est valide avec la paire user/mot de passe donnée.