La commande mount de Linux permet de connecter un file-system sur un folder linux; le plus simple et le plus connu étant le fameux mount /dev/sbxx; mais Linux est tellement capable de faire mieux (et plus).
Ce billet/article est avant tout un post-it de mes notes.
On peut lister les partitions d'une image, au même titre qu'une “vrai” disque:
root@hades-vm:~# fdisk -l /home/frater/images/recalbox.img Disk recalbox.img: 1.9 GiB, 2002632192 bytes, 3911391 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00000000 Device Boot Start End Sectors Size Id Type recalbox.img1 1263 132334 131072 64M c W95 FAT32 (LBA) recalbox.img2 132335 3911390 3779056 1.8G 83 Linux
les deux paramètres qui nous intéressent ici sont “Units” et la colonne “Start”; ces informations font nous permettre de calculer l'offset DANS le fichier image que vous désirez monter.
ici, notre bloc size (unit) est de 512 bytes.
1263*512 = 646656 # offset for partition #1 132335*512 = 67755520 # offset for partition #2
Une fois cette valeur d'offset calculée, on peut la passer à la commande mount, via l'option “-o”:
root@hades-vm:~# mkdir /mnt/rec-img # create the mounting folder (if not already present) root@hades-vm:~# mount -o loop,offset=67755520 recalbox.img /mnt/rec-img/ # mount second partition
Comme le format qcow2 est un format distribuable via réseau, il est plus simple pour monter une image qcow2 de passer par le device ndb (network block device).
On Linux, network block device (NBD) is a network protocol that can be used to forward a block device (typically a hard disk or partition) from one machine to a second machine. As an example, a local machine can access a hard disk drive that is attached to another computer.
nous allons donc monter notre image qcow2, sur un device nbd; mais avant il convient de paramétrer un peu le device que nous allons utiliser; notamment en augmentant le nombre de partitions par device à 8 (qui est par défaut à 0); par défaut nbd créé 16 device, ce qui est beaucoup; nous allons nous limiter à 2 devices.
root@pve02:~# modprobe nbd nbds_max=2 root@pve02:~# modprobe nbd max_part=8 root@pve02:~# ls -la /dev/nbd* brw-rw---- 1 root disk 43, 0 Jul 31 23:19 /dev/nbd0 brw-rw---- 1 root disk 43, 32 Jul 31 23:19 /dev/nbd1
Une fois nos devices créer, on peut y connecter notre image qcow2.
root@pve02:~# qemu-nbd --connect=/dev/nbd0 /mnt/pve/nfs-vmstore/images/101/vm-101-disk-0.qcow2
pour vérifier que la connection est effective, on va lister les partitions:
root@pve02:~# fdisk /dev/nbd0 -l Disk /dev/nbd0: 64 GiB, 68719476736 bytes, 134217728 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 036E89F2-400F-4BB8-B1D5-58FF2850708F Device Start End Sectors Size Type /dev/nbd0p1 2048 923647 921600 450M Windows recovery environment /dev/nbd0p2 923648 1126399 202752 99M EFI System /dev/nbd0p3 1126912 1159167 32256 15.8M Microsoft reserved /dev/nbd0p4 1159168 134215679 133056512 63.4G Microsoft basic data /dev/nbd0p5 1126400 1126911 512 256K unknown Partition table entries are not in disk order.
Si fdisk affiche des partitions, comme pour un disque, c'est gagné; il suffit de monter la/les partitions voulues via la commande mount classique:
root@pve02:~# mount /def/nbd0p4 /mnt/loop
on peut ensuite gérer les fichiers/dossiers normalement:
root@pve02:~# ls -lah /mnt/loop/ total 9.3G dr-x------ 1 root root 4.0K Jul 28 18:11 . drwxr-xr-x 4 root root 4.0K Jul 31 21:51 .. dr-x------ 1 root root 0 Jun 17 2022 '$Recycle.Bin' -r-------- 1 root root 381K Feb 2 2018 bootmgr -r-------- 1 root root 1 Jul 16 2016 BOOTNXT dr-x------ 1 root root 0 Jun 17 2022 'Documents and Settings' -r-------- 1 root root 8.0G Jul 28 17:30 hiberfil.sys dr-x------ 1 root root 0 Jul 3 2022 inetpub -r-------- 1 root root 1.3G Jul 28 17:30 pagefile.sys dr-x------ 1 root root 0 Jun 18 2022 PerfLogs dr-x------ 1 root root 4.0K Jul 25 23:23 ProgramData dr-x------ 1 root root 8.0K Jul 25 23:23 'Program Files' dr-x------ 1 root root 4.0K Jul 26 15:06 'Program Files (x86)' dr-x------ 1 root root 4.0K Jul 3 2022 Python26 dr-x------ 1 root root 0 Jun 17 2022 Recovery dr-x------ 1 root root 4.0K Aug 21 2022 'System Volume Information' dr-x------ 1 root root 4.0K Jul 3 2022 Users dr-x------ 1 root root 24K May 20 2023 Windows
Pour libérer l'image, il faut démonter umount et ensuite déconnecter l'image:
root@pve02:~# umount /mnt/loop/ root@pve02:~# qemu-nbd --disconnect /dev/nbd0 /dev/nbd0 disconnected
si vous n'avez pas d'autre images a traiter; vous pouvez retirer les devices :
root@pve02:~# rmmod nbd
Qui n'a jamais rêver de pouvoir modifier des fichiers distants sans pour autant se charger de les uploader?
Cette note suppose que vous avez 2 linux disponibles (je n'ai pas tester via ces machines Windows).
sur le “serveur” (pc distant) il faut s'assurer d'avoir un user local pouvant se connecter en SSH et qui dispose des droits suffisant sur le folder que l'on désire accéder.
sur le “client” il faut installer les outils sshfs:
frater@hades-vm:~# apt install sshfs Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: fuse3 The following NEW packages will be installed: fuse3 sshfs 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 81.6 kB of archives. After this operation, 227 kB of additional disk space will be used. Do you want to continue? [Y/n] y Get:1 http://deb.debian.org/debian bookworm/main amd64 fuse3 amd64 3.14.0-4 [35.9 kB] Get:2 http://deb.debian.org/debian bookworm/main amd64 sshfs amd64 3.7.3-1.1 [45.6 kB] Fetched 81.6 kB in 0s (519 kB/s) Selecting previously unselected package fuse3. (Reading database ... 42718 files and directories currently installed.) Preparing to unpack .../fuse3_3.14.0-4_amd64.deb ... Unpacking fuse3 (3.14.0-4) ... Selecting previously unselected package sshfs. Preparing to unpack .../sshfs_3.7.3-1.1_amd64.deb ... Unpacking sshfs (3.7.3-1.1) ... Setting up fuse3 (3.14.0-4) ... Setting up sshfs (3.7.3-1.1) ... frater@hades-vm:~# modprobe fuse # not sure that it's still necessary
mount first time
frater@hades-vm:~# sshfs [-o idmap=user,allow_other] [-C] [-p 1234] remote_ssh_frater@heaven-hades.noloop.cloud:/home/frater /mnt/remote-heaven/ The authenticity of host '172.16.0.254 (172.16.0.254)' can't be established. ED25519 key fingerprint is SHA256: C9tEvcWVV6U9GNYfwQVpRiyxwfmnEBEovmsYqShk6k5. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes (remote_ssh_frater@heaven-hades.noloop.cloud) Password for remote_ssh_frater@heaven-hades:
Vous devez confirmer et vérifier votre fingerprint.
Vous devrez également vous authentifier en suivant les politiques d’authentification du serveur distant (mot de passe et/ou clé publique, mfa, etc.).
Si aucune erreur n'est affichée, vous pourrez lire et écrire dans le dossier /home/frater du serveur, via le folder local /mnt/remote-heaven/.
Paramètres
| argument | description |
|---|---|
| -C | enable compression during transfert |
| -o | options to apply (see below) |
ssh options (-o)
| option | descr |
|---|---|
| idmap | sshfs peut convertir automatiquement les identifiants des utilisateurs, groupes locaux et distants. Utilisez l'option idmap=none pas de conversion (par défaut)Utilisez l'option idmap=user pour convertir les valeurs UID/GID de l'utilisateur distant par les valeurs UID/GID locale |
allow_other : allow other users to use the mount point (ex root or other local user)
Clé publique - clé privée
Si vous désirez monter ce folder automatiquement (sans mot de passe) il est possible de préciser un couple de clés publique-privée.
frater@hades-vm:~# ssh-keygen
Nous allons commencer par créer une clé publique, lors de la génération, ne précisez pas de “passphrase”, a moins que vous ne désiriez entrer cette phrase a chaque fois; c'est un bon réflexe pour la sécurité, par contre c'est pénible pour l'automation.
frater@hades-vm:~# ssh-copy-id -i /$HOME/.ssh/id_rsa remote_user_name@servername-or-ip
Via cette commande, nous allons copier la clé publique sur le serveur, durant cette commande, il vous sera demandé (une dernière fois) le mot de passe de 'remote_user_name'; si vous avez préciser une passphrase, elle vous sera également demandée.
Linux Distant on peut vérifier la bonne copie des clés, sur le “serveur” distant, il suffit de vérifier le fichier des clés autorisées:
frater@hades-vm:~# cat /home/remote_user_name/.ssh/authorized_keys ssh-rsa AAAAB3NzaC1... ...2ahpw== frater@hades-vm
le fichier commence par un “ssh-rsa”, une série de chiffres et lettre (la clé) et se termine par des informations de connexion user_name@remote_client, c'est habituellement user_name@local_client_ip_or_name.
En local
pour vérifier si l'échange de clés est correctement installé, on peut faire un test via la commande suivante:
ssh remote_user@servername-or-ip
Il est possible de monter également une partition, une image “formaté” en NTFS.
Monter une partition
mount -t NTFS -o ro /dev/sdxx /mnt/loop
Monter un fichier image
mount -t vfat -o loop,ro,noexec image.img /mnt/loop
il est également possible de préciser un offset dans l'image:
mount -t vfat -o loop,ro,noexec,offset=63 image.img /mnt/loop
install pre-requis
root@hades-vm:~# apt-get install cifs-utils
temporary mount:
root@hades-vm:~# mount -t cifs //[SERVER.DOMAIN.LOCAL]/[SHARE] /mnt/[MOUNT_DIR] -o username=[USERNAME],password=[PASSWORD],domain=[DOMAIN_OR_WORKGROUP]
or if you have credentials file.
root@hades-vm:~# mount -t cifs //[SERVER.DOMAIN.LOCAL]/[SHARE] /mnt/[MOUNT_DIR] -o credentials=/root/.smbcredentials
permanent mount
root@hades-vm:~# nano /etc/fstab
il faut ensuite ajouter cette ligne à la fin du fichier:
//[SERVER.DOMAIN.LOCAL]/[SHARE] /mnt/[MOUNT_DIR] cifs credentials=/etc/.smbcredentials,iocharset=utf8 0 0
credentials file
Lors du montage du partage, il est possible de préciser un fichier d'authentification; cette précision permet également de monter le partage lors du boot de linux.
Dans le fichier fstab, on a préciser un fichier .smbcredentials (localisé dans le répertoire etc du système); il est important limiter la lecture/modifications aux seuls utilisateurs qui doivent accéder/modifier ce fichier
username=[USERNAME] password=[PASSWORD] domain=[DOMAIN_OR_WORKGROUP]
install “drivers”
root@hades-vm:~# apt-get install hfsplus
mount drive in Read Only
root@hades-vm:~# mkdir /media/loop # create folder if needed root@hades-vm:~# mount -o ro /dev/hdxx /media/loop -t hfsplus
root@hades-vm:~# umount /media/loop