avantage désavantege d'un /home séparé

crap0 · 10-09-2019 09:03:14

Bonjour

J'aurais aimé connaître les avantage et désavantage d'un /home séparé.
Ce qu'il faudra prendre en compte si je met en place ceci.

J'ai un disque interne assez grand pour me permettre une partition assez grande pour acceuillir le système.
J'utilise régulièrement Back-in-time pour mes sauvegarde.
Ainsi que rsync, ...
J'utilise debian 9 sous Xfce et Mate.
Comme c'est un ordi destiné à la production musical, j'y installe les méta-paquets (la plus part) de Librazik-2. Comprenant un noyau en temps réel, des configuration système, des logiciels, optimisation système, ...
Tout cela en dual-boot avec un osx en début de disque.

Pour compléter:
Je crois savoir qu'il n'est pas recommandé de mettre un même /home pour différente système de fichier système.
Puis je utiliser par contre une même zone pour la swap si j'installe deux linux sur un même disque ?

Si d'autres points doivent être abordé, n'hésitez pas !!

Merci
a+

melissa6969 · 10-09-2019 09:55:13

l'avantage d'un /home séparé.??
bah y a que des avantages en faite, tu gardes tes config en cas de crash système, et en cas de réinstallation.
si ton disque principal contenant ta /racine meurt, tu as toujours ton /home et donc tu t'épargnes des heures de configuration pour chaque logiciel.
dans le cas d'un SSD, c'est stupide d'y mettre le /home, puisqu'il y a aucun avantage niveau vitesse pour lancer les logiciels.
ton /home séparé tu peux l'agrandir et le réduire sans risquer de casser la distribution.

par contre c'est stupide de garder le /home avec toutes ces données dedans, si on fait un /home séparé autant aller jusqu'au bout des choses dans la logique et surtout la pratique.

autrement dit
un /home séparé c'est bien, mais un /home séparé + une /data commune dans le cas de multiboot c'est encore mieux.

chose que j'ai.

une /racine (ça va de soi) pour mes deux OS sur mon SSD
un petit /home de 20 Go (qui est surdimensionné mais je prévois large) pour chaque OS sur mon HDD
et une /data commune à mes deux OS sur le reste du HDD
comme ça je retrouve toutes mes données peu importe l'OS utilisé.
et bien évidement, faut faire en sorte que tes dossiers "téléchargements, vidéos, images, doc, etc" pointent sur la data sinon ça n'a aucun sens.

les avantages c'est que lors des backups du /home avec rsync, ça te sauvegarde que tes fichiers de conf de tes logiciels.
ta /data contient tes données, donc ça se sauvegarde en double sur un hdd externe, et non avec rsync qui alourdit bêtement les backups.
et les /racines tu sauvegardes avec clonezilla, et t'es tranquille, en cas de gros crashs irréparables, tu retrouves ton système fonctionnel en 5 minutes avec tous tes logiciels déjà configurés.

et NON on met pas un /home commun pour deux Linux, sauf si tu aimes avoir des soucis en tout genre.
si une version de logiciel est différente d'un linux à un autre, y aura à un moment donné des conflits, résultat une des versions du logiciel va écraser l'autre, et donc ça sera le foutoir.

pour le swap je pense que oui, mais sans certitude, j'ai pas de swap sur ma machine donc je sais pas (puis avec les quantité de ram qu'on a, le swap est presque stupide, seul moment où on l'utilise, c'est en cas d'hibernation de la machine)...

Dernière modification par melissa6969 (10-09-2019 09:59:30)

raleur · 10-09-2019 10:15:17

Avantages de /home séparé :
- Facilite la maintenance du système (sauvegarde et restauration, réparation, réinstallation...)
- Limite l'étendue d'une éventuelle corruption des données ou du système de fichiers

Inconvénient :
- Risque de mal répartir l'espace disque entre / et /home. On peut atténuer ce risque en utilisant LVM intelligemment (donc pas avec le partitionnement assisté).

crap0 a écrit :

Je crois savoir qu'il n'est pas recommandé de mettre un même /home pour différente système de fichier système.

Qu'entends-tu par "différente système de fichier système" ?
Partager un même /home entre plusieurs systèmes ? En effet cela peut présenter des inconvénients car les fichiers de configuration du profil utilisateur peuvent être différents et incompatibles entre deux systèmes. Il peut être préférable de créer un système de fichiers spécifique pour le stockage et le partage des données entre plusieurs systèmes.

Dans tous les cas il faut faire très attention à la gestion des permissions et ne pas oublier que sur disque les utilisateurs et groupes sont identifiés par leurs UID/GID numériques et non par leur nom d'utilisateur/groupe, et que la correspondance entre les deux est propre à chaque système (cf. /etc/passwd et /etc/group).

crap0 a écrit :

Puis je utiliser par contre une même zone pour la swap si j'installe deux linux sur un même disque ?

Oui, mais...
Il est fréquent que l'installation d'un second système reformate le swap partagé et change son UUID. Si le premier système utilise l'UUID pour identifier le swap, il ne le trouvera plus, causant erreurs et délais au démarrage.
Si le swap doit être partagé, je suggère plutôt de ne pas le marquer à utiliser lors de l'installation du second système, et de le déclarer après l'installation.
D'autre part avec un swap partagé il n'est pas possible d'hiberner un système et de redémarrer avec l'autre. Cela détruirait l'image d'hibernation du premier et empêcherait sa reprise. A noter que ce n'est pas possible non plus si les deux systèmes ont un système de fichiers partagé.

raleur · 10-09-2019 10:21:11

melissa6969 a écrit :

dans le cas d'un SSD, c'est stupide d'y mettre le /home, puisqu'il y a aucun avantage niveau vitesse pour lancer les logiciels.

Je ne suis pas d'accord. Vu la foule de petits fichiers que l'environnement de bureau ou un logiciel comme firefox stockent dans le profil utilisateur, ça m'étonnerait qu'ils ne bénéficient pas de la vitesse du SSD pour /home.

Dernière modification par raleur (10-09-2019 10:22:31)

melissa6969 · 10-09-2019 10:40:02

raleur a écrit :

Je ne suis pas d'accord. Vu la foule de petits fichiers que l'environnement de bureau ou un logiciel comme firefox stockent dans le profil utilisateur, ça m'étonnerait qu'ils ne bénéficient pas de la vitesse du SSD pour /home.

Sincérement chez moi je clique sur le logo Firefox, et 1-2 secondes + tard il est lancé et opérationnel.
pourtant le dossier .mozilla est bien dans mon /home dans le HDD (le hdd a l'âge de mon pc, soit 6 ans et c'est un 5400 rpm, donc pas un foudre de guerre)

le seul logiciel qui met + de temps à se charger c'est gimp (j'ai le greffon gmic que j'installe manuellement dans le dossier de conf de gimp, et lui me ralentit le démarrage c'est vrai, et c'est à ce moment où j'entends les rares fois mon hdd gratter)

crap0 · 10-09-2019 23:50:25

Merci cool

donc je m'y lance.

J'entendais par système de fichier : /racine
erreur de choix de mots

reste que sur ma Debian, y a pas trop de possibilités pour avoir un partition /data qui pourrait aussi servir à un osx.
le seul système à ma vue est le exFat pour cette partition...
osx, ok a ce niveau mais pas ma Debian 9, j'arrive jamais à y écrire dessus (lire oui par contre quand elle veut bien se monter).

comment faire pour faire pointer les dossiers images, video, documents and co vers cette partition /data

merci
a+

Dernière modification par crap0 (10-09-2019 23:51:57)

melissa6969 · 11-09-2019 09:32:22

du exfat.???
ha oui ça complique pas mal les choses en faite, linux sait le lire mais bon ça reste un choix peu utilisé surtout pour une partition /data (en général on part sur du ext, ou du ntfs)

j'y connais rien en Mac et donc ni en leur OS, alors je peux pas te donner + de conseils que ça.
même pour monter une partition /data sur un mac je sais même pas si c'est simple à faire, etc, j'avoue que là ça dépasse mes compétences, y faire entre plusieurs linux, je maitrise, mais après.....

Dernière modification par melissa6969 (11-09-2019 09:32:58)

raleur · 11-09-2019 14:16:51

Le support d'exFAT pour Linux utilise FUSE (comme ntfs-3g), donc les performances risquent d'être mauvaises.

Tu as essayé le système de fichiers UDF ? C'est un format qui supporte les permissions Unix, supporté nativement par Linux, Windows et probablement par MacOS puisqu'il est utilisé sur les CD et DVD réinscriptibles.

crap0 · 11-09-2019 21:13:11

non, même jamais entendu parlé UDF
je vais aller voir.

comment je format en UDF ??

(merci aussi et à tous)

raleur · 11-09-2019 22:27:59

Comme pour n'importe quel système de fichiers : avec mkfs.udf, qui pointe vers mkudffs installé par le paquet udftools.

crap0 · 28-09-2019 20:19:21

merci vais essayer

Debeee · 30-09-2019 20:54:50

Bonjour,
pour la partition data, tu as essayé de formater en HFS+ (format mac), faisable avec Gparted ?
C'est plutôt bien supporté par la debian avec les outils ad hoc : hsplus, hfsprogs, hfsutils, en lecture et écriture.
J'échange des fichiers entre mac et debian comme ça, j'ai des fois des soucis de propriété de fichiers/dossiers mais ça vaut le coup que tu essaye.
Par contre, tu peux mettre du fat32, mais le mac copie tout un tas de fichiers supplémentaires en .xx et ._xx pour compenser les manques de ce format. En plus, le fat32 ne supporte pas les liens unix (très pénible)
Jamais essayé exFAT...

raleur · 01-10-2019 09:39:18

J'étais resté dans l'idée que Linux ne savait monter un système de fichiers HFS ou HFS+ qu'en lecture seule. Mais s'il gère l'écriture, je pense que c'est la solution à privilégier pour le partage de données avec MacOS puisqu'il s'agit d'un système de fichiers natif de cet OS.

Si je comprends bien, les programmes des paquets hfsutils et hfsplus permettent de manipuler le contenu d'un système de fichiers HFS ou HFS+ sans le monter au sens traditionnel d'Unix sur un point de montage (comme les outils du paquets mtools avec les systèmes de fichiers FAT). On ne peut pas utiliser d'autres programmes pour y accéder directement.

Debeee a écrit :

fat32 ne supporte pas les liens unix

Tu parles des liens symboliques et des liens durs ? D'après la documentation du noyau, HFS non plus.

Dernière modification par raleur (01-10-2019 09:51:43)

Debeee · 01-10-2019 13:36:22

Oui, il faut les paquets cités pour manipuler les fichiers sur un support HFS+ macOs. D'ailleurs, si tu ne les as pas, tu ne peux pas formater une partition en HFS+ depuis Gparted, l'item est grisé.

On ne peut pas utiliser d'autres programmes pour y accéder directement.

Tu veux dire qu'on peut juste copier des fichiers entre disques et c'est tout ?

Test 1 : j'ai activé le partage de fichiers sur mon mac. Et depuis caja sur un pc avec debian 10 mate, je vais dans "parcourir le réseau", et je vois mon mac. Je m'y connecte avec l'ID et le pass du mac. J'ai accès à presque tout (voir plus bas).
J'ai essayé d'ouvrir par double clic un fichier libre office qui est sur le mac à partir de caja sous debian : échec
J'ai copié un fichier gnuméric du pc sur le mac (via caja), et je l'ai ouvert par double-clic depuis caja : ça marche. et je peux le modifier et le réenregistrer sur le mac, toujours depuis caja.

Test 2 : j'ai copié le fichier libre office récalcitrant du test 1 sur clé usb formatée HFS+, mis la clé sur le pc, et directement double-cliqué le fichier depuis caja (pas de copie sur un support ext4 du pc) : libre office l'a bien ouvert cette fois, je l'ai modifié, réenregistré sur la clé (donc HFS), et relu sur le mac => modifes bien prises en compte

Donc, ça a l'air assez souple quand même. Y'a l'échec avec LO via le réseau, faut que je voie ça de plus près, c'est un logiciel assez spécial, y'a peut-être une incompatibilité qqpart. Mais bon, ça ouvre un fichier LO mis sur un support HFS, et tu peux le modifier et le réenregistrer : pas de pb pour crap0 et son utilisation par exemple.
[edit2] retest via le réseau : c'est bien LO qui merde. Si je double-clique un fichier rtf du mac depuis caja via le réseau, LO commence à se lancer, puis plus rien ; si je fais "ouvrir avec pluma", ça ouvre instantanément. J'ai aussi essayé depuis caja : dupliquer une photo du mac sur le mac, l'éditer avec gThumb (TB ce logiciel) depuis le pc, enregistrement : sur le mac, on constate que tout a bien marché. Autre truc rigolo, le mac stocke certains dossiers sous forme de fichiers, appelés paquets (ex : les applis). Depuis caja, on a directement accès au contenu de ces paquets (visibles sur le mac en faisant "afficher le contenu du paquet") [edit2]

Après, il y a des pb de permissions sur certains dossiers : par ex, j'ai un support HFS avec une sauvegarde des fichiers de mon mac, le dossier "bibliothèque" (library en GB) est inaccessible, ni en lecture ni en écriture depuis caja. C'est le seul, mais il a un statut spécial dans le mac.
[edit] je viens de tester, via le réseau, depuis caja, j'ai accès en lecture/écriture au dossier "bibliothèque" du mac (nommé Library dans caja), je peux voir le contenu et effacer des fichiers par ex. [/edit]
J'ai aussi copié depuis le mac un dossier nommé "admin" ce matin sur une clé usb HFS ; sur le pc, c'était en lecture seule, mais j'avais accès aux fichiers et possibilité de les copier sur le pc.
Pourtant, ces fichiers n'ont pas d'accès restreint sur le mac...

Pour les liens, ce sont des liens symboliques je pense (item "créer un lien" sous caja), et effectivement, je viens de tester, ce n'est pas pris en charge non plus avec un support HFS.

Dernière modification par Debeee (01-10-2019 14:09:31)

raleur · 02-10-2019 13:45:54

Debeee a écrit :

Oui, il faut les paquets cités pour manipuler les fichiers sur un support HFS+ macOs.

Non, on n'a pas besoin de ces paquets pour manipuler les fichiers d'un volume HFS ou HFS+. Si on le monte de façon traditionnelle sur un répertoire (avec la commande "mount" ou action équivalente), on peut manipuler ses fichiers avec n'importe quel programme.

Debeee a écrit :

D'ailleurs, si tu ne les as pas, tu ne peux pas formater une partition en HFS+ depuis Gparted, l'item est grisé.

On n'a pas besoin des trois. Le paquet hfsprogs contient les programmes mkfs et fsck pour formater et vérifier HFS et HFS+ ; hfsutils contient le programme hformat pour formater en HFS ; hfsplus contient le programme hpfsck pour vérifier HFS+. D'après https://gparted.org/features.php, Gparted utilise hfsprogs pour HFS+ et hfsutils pour HFS (ce qui est un peu dommage, hfsprogs gérant les deux et permettant de vérifier HFS, ce que hfsutils ne permet pas).

Debeee a écrit :

Tu veux dire qu'on peut juste copier des fichiers entre disques et c'est tout ?

Je veux dire qu'il y a deux façons de manipuler les fichiers d'un volume HFS ou HFS+. Soit on monte le volume de façon classique et on peut faire ce qu'on veut (dans les limites des caractéristiques du système de fichiers), soit on ne le monte pas et on ne peut manipuler ses fichiers qu'avec les commandes spéciales des paquets hfsutils (pour HFS) ou hfsplus (pour HFS+). C'est la même chose qu'avec un volume FAT : on peut soit le monter, soit manipuler ses fichiers avec les commandes du paquet mtools sans le monter. Pour manipuler les fichiers d'un volume non monté il faut avoir les permissions d'accès au fichier image ou au périphérique (disque, partition) qui le contient. Normalement il faut être root ou member du groupe "disk" pour avoir accès aux disques et partitions. Evidemment il ne faut pas utiliser les commandes d'accès direct sur un volume monté, sinon on risque de l'endommager.

Debeee a écrit :

Test 1 : j'ai activé le partage de fichiers sur mon mac. Et depuis caja sur un pc avec debian 10 mate, je vais dans "parcourir le réseau", et je vois mon mac. Je m'y connecte avec l'ID et le pass du mac.

C'est hors sujet car le format HFS(+) ne concerne que les accès aux disques locaux. Le partage en réseau est indépendant du type de système de fichiers local et utilise un protocole de partage de fichiers en réseau comme NFS (Unix) ou SMB/CIFS (Windows/Samba) ou AppleShare (MacOS).

Dernière modification par raleur (02-10-2019 13:48:37)

crap0 · 03-10-2019 06:59:08

Bonjour

voilà: simple note...

j'ai essayer le format UDF pour ma partition d'échange : debian 9 & 10 en installant le paquet udftools > ok, no problèmes ... Mais c'est mon mac osx qui ne veut pas dés lors la reconnaitre et donc la montée ... (j'ai pas chercher: peut-être un logiciel à installer sur osx ?)

Après installation de touts les paquets pour gérer les formats de fichier osx, ma debian, peut formater depuis gparted, lire et écrire sur celle-ci avec thunnar, psmanfm, ... . Mon osx (macOs) -biensur- fait tout pareille.

J'ai donc ma partition d'échange en HFS+.

- Pour le reste et pour revenir au /home séparé.
Je n'ai pas créer de /home séparé a proprement parlé.
Juste par systèmes macOs et différentes Debian, une "petite" partition contenant le système et le-s home-s ... 80Go pour la Debian principale (enfin, je crois me rappeler) ... par contre je n'utiliserais pas a proprement parlé le /home pour mes fichiers, ... j'utiliserais cette partition d'échange en hfs+ unique pour touts mes systèmes. (un dossier téléchargements sur celle-ci sur lequel touts mes Firefox, Brave Browser, ... ont été renseigner comme comme celui-ci étant l'emplacement des download) ...
- Comment faire pointé n'importe quel dossier de destination vers un autre emplacement: cela pourrait m'éviter de m'y perdre ... comment demander que tout ce qui est placé dans /home/user/Documents soit en faite placé dans /volumes/user/name_volume/Documents (par exemple) ?
- Sais pas si c'est judicieux mais créer un home séparé pour mes deux debian et osx (4 aux total donc, allé savoir mais 4 pour moi, c'est comme ça

) et en plus une partition d'échange .. enfin beaucoup de tralala (total environs 9 partitions si on ne compte pas les partition recovery d'osx, d'éventuel swap et autres...).
Là, ici, 5 partitions et si besoin de réinstallation: c'est juste un tout petit 80Go à réécrire et pas de bidule plus compliqué.

- Je continue à utiliser backintime-gnome pour des sauvegardes des systèmes Debian ... rsync, aussi si besoin et que je trouve utile et rapide. Tout ça parce que j'y suis habitué mais j'avoue, enfin essayer clonezilla... serrait un atout judicieux supplémentaire ! Reste, je vais aller voir, mais si je peux faire des sauvegarde incrémentable avec backintime de cette partition d'échange hfs+, alors, je serrais heureux et satisfait. Si non, rechercher un tutto pour créer un rsync qui pourrait garder deux trois voir plus de version antérieur de mes changements de fichiers et dossiers : je crois déjà avoir vu ça, de mémoire, c'est pas plus compliqué que ça.

- Cela étant dit avec rsync, je l'utilise comme-ci : rsync -av --dellete <dossier_à_sauvegarder> <destination_de_le_sauvegarde>
(de 1: suis je ok, déjà, à ce niveau ... dernièrement, j'ai vu dans un forum l'option -f en plus ...)
Avec ce fameux format HFS+, y a t-il une subtilité pour par exemple les droits et/ou autres.

raleur · 03-10-2019 09:05:54

crap0 a écrit :

Comment faire pointé n'importe quel dossier de destination vers un autre emplacement: cela pourrait m'éviter de m'y perdre ... comment demander que tout ce qui est placé dans /home/user/Documents soit en faite placé dans /volumes/user/name_volume/Documents (par exemple) ?

Voici deux possibilités :

a) Avec un lien symbolique qui remplace le répertoire d'origine et pointe vers le repertoire de destination.
Après avoir déplacé le répertoire /home/user/Documents et son contenu dans /volumes/user/name_volume,

ln -s /volumes/user/name_volume/Documents /home/user/Documents

b) Avec un "bind mount" du répertoire de destination sur le répertoire d'origine.
Après avoir déplacé le contenu de /home/user/Documents dans /volumes/user/name_volume/Documents,

mount --bind /volumes/user/name_volume/Documents /home/user/Documents

Pour automatiser le "bind mount" au démarrage dans /etc/fstab :

/volumes/user/name_volume/Documents /home/user/Documents hfsplus bind

Bien sûr il faut que le volume HFS+ soit préalablement monté. Comment l'as-tu monté ?

crap0 a écrit :

Avec ce fameux format HFS+, y a t-il une subtilité pour par exemple les droits et/ou autres.

Oui. HFS et HFS+ ne sont pas des systèmes de fichiers Unix, il ne permettent pas la modification de certaines propriétés comme l'utilisateur et le groupe propriétaires et certains bits de permissions, la création de fichiers spéciaux comme les liens physiques ou symboliques (mais un lien symbolique créé dans un autre système de fichiers peut pointer dessus). Les utilisateurs et groupes propriétaires apparents sont définis au montage.
Sources :
https://git.kernel.org/pub/scm/linux/ke … xt?h=v4.19
https://git.kernel.org/pub/scm/linux/ke … xt?h=v4.19
Je découvre tout cela, n'ayant aucune expérience avec HFS(+) ni MacOS.

EDIT :
Vérification faite, ces restrictions ne s'appliquent qu'à HFS. HFS+ supporte les permissions Unix, les liens physiques et symboliques.

Dernière modification par raleur (05-10-2019 13:23:02)

crap0 · 03-10-2019 09:35:36

ok merci raleur (et autres aussi)
pas le temps, là, sur le champ mais vais faire tout ça.

par contre pour te répondre rapidement
comment ais je monté ma partition interne HFS+
- je suis généralement sous Xfce ... sous cette environnement, les disques ne se montent pas directement ou autres mais apparaissent tout de même sur le bureau et emplacements (c'est un minimum logique si ils sont reconnu, je pense te j'ai envie de dire) .. et d'un simple double clic sur l'image grisé (correspondant à un disque non-monté) et si je me rappel bien* : mot de passe ... et le volume se monte.

Je devrai renseigner le fichier fstab pour monter directement au démarrage de session, ça m'évitera de potentiel "prise de tête" ... enfin c'est agréablement exagérer mais voilà, cela automatiserait ce double clic ...

* je ne sais plus réellement si un password a été demandé ... peut-être est-ce pour la partition de mon osx installé sur cet ordi en dual boot... ce qui me paraitrait plus logique .. cette partition d'osx est aussi en grisée sur mon bureau et autres à l'ouverture de session...

voilà grosso modo.

Maintenent je me passionne de plus en plus pour d'autres gestionnaire de bureau/fenêtres aux saveurs "plus" geek : i3, twm, dwm, ... avant c'était lxde suivit de lxqt ... et tout ça en plus de mate conseiller pour ma distribution MAO Librazik2 sous debian 9.
J'aurais peut-être d'autres résultats, similaires mais autres, avec ces différents wm ...

je reviendrais faire mon topo une fois que j'aurais suivis tes conseilles pour pointé mes dossiers là ou il faut

a++ merci et Croac !

raleur · 03-10-2019 09:44:14

crap0 a écrit :

Je devrai renseigner le fichier fstab pour monter directement au démarrage de session

Il faudra peut-être spécifier les options de montage uid, gid et/ou umask pour définir les permissions.

Debeee · 04-10-2019 14:53:12

#15 : Non, on n'a pas besoin de ces paquets pour manipuler les fichiers d'un volume HFS ou HFS+. Si on le monte de façon traditionnelle sur un répertoire (avec la commande "mount" ou action équivalente), on peut manipuler ses fichiers avec n'importe quel programme.

Comprends pas, on peut à la rigueur lire (mal), mais pas écrire.

On n'a pas besoin des trois. Le paquet hfsprogs contient les programmes mkfs et fsck pour formater et vérifier HFS et HFS+

Sans doute vrai. Je n'ai pas ta connaissance et j'ai fait utilitaire : j'ai chargé tout ce que j'ai trouvé avec HFS dans synaptic. De toutes façons, ça ne fait jamais que qq centaines de ko

Sinon, j'ai toujours pas bien compris ta notion de "monter" le disque, et j'ai l'impression que crap0 est pareil.
En pratique, j'avais coché une option quelque part dans la config système de mate pour que les volumes externes branchés montent automatiquement sur le bureau : ce qui se fait bien. Mes volumes ont une adresse qui part de /media/monlogin/nomduvolume. Jamais je ne m'emm… à faire du mount en ligne de commande, mais je suppose que mate le fait pour moi ? J'ai bon ? Et dans tous les cas, je peux maniper tous mes fichiers comme indiqué au #14.
Pour les disques internes (je n'ai pas de HFS interne), oui, il faut les déclarer dans le fstab (j'avais installé une mint lmde2 Betsy, elle avait fait ça toute seule, avec tous les droits en lecture/écriture => mes disques étaient tous dispo après l'installation). Si tu les mets dans fstab, le système les monte ?

A l'intention de crap0 : oui, il faut mettre le disque HFS dans le fstab, et pour les droits, si tu donnes tous les droits en lecture / écriture en mode root à ce disque, c'est bon, inutile de le signaler dans fstab (les options sont compliquées pour qui maîtrise moyennement)

Dernier petit truc, si tu utilises Rsync : je galère de ouf avec ça en ce moment, mais j'ai réussi à trouver quelques trucs (pense à l'option -n pour faire une simulation à blanc, pour voir ce que ta synchro va faire mais sans qu'elle ne le fasse, histoire de pas pourrir ton backup). Avec HFS+ il y a deux composantes par fichier : les data et les ressources. Si tu veux copier les ressources (icônes, infos spéciales sur un fichier…) sur un support autre que HFS+, faut mettre l'option -E. Par contre, ça te copie une tétrachiée de fichiers avec le même nom que tes fichiers mais précédés de ._ => c'est très long à copier, ça le refait à chaque backup, donc c'est très pénible.
Si quelqu'un a d'autres infos là dessus, je prends…

raleur · 05-10-2019 13:42:11

Debeee a écrit :

Comprends pas, on peut à la rigueur lire (mal), mais pas écrire.

Je ne comprends pas de quoi tu parles.

Debeee a écrit :

Sinon, j'ai toujours pas bien compris ta notion de "monter" le disque

Ce n'est pas "ma" notion, c'est celle de tous les systèmes de type Unix : rendre accessible le contenu d'un volume dans un répertoire appelé "point de montage". La commande traditionnelle pour cela est "mount".

Debeee a écrit :

Mes volumes ont une adresse qui part de /media/monlogin/nomduvolume

Ils sont donc montés sur ces points de montage.

Debeee a écrit :

je suppose que mate le fait pour moi

Oui, les environnements de bureau automatisent plus ou moins le montage automatique des volumes amovibles.

Debeee a écrit :

Et dans tous les cas, je peux maniper tous mes fichiers comme indiqué au #14.

Sans avoir besoin d'utiliser les commandes des paquets hfsutils ou hfsplus, puisque le volume est monté. Comme je disais.
Ces paquets ne contiennent aucun démon, service ou pilote, contrairement à ntfs-3g qui contient un pilote pour NTFS. Tu n'en as pas besoin si tu n'utilises pas les programmes qu'ils contiennent. Tu as seulement besoin du paquet hfsprogs pour formater ou vérifier un volume HFS+, soit en ligne de commande soit par l'intermédiaire de Gparted.

Debeee a écrit :

Si tu les mets dans fstab, le système les monte ?

Oui.

Debeee a écrit :

pour les droits, si tu donnes tous les droits en lecture / écriture en mode root à ce disque, c'est bon, inutile de le signaler dans fstab

En effet HFS+ supporte les permissions Unix standard (contrairement à ce que j'ai écrit dans mon message #17 que j'ai amendé) donc on peut gérer les permissions directement dans l'arborescence. Les options de montage ne servent qu'à spécifier les propriétaires et permissions des fichiers pour lesquels ces informations ne sont pas initialisées.

Debeee · 06-10-2019 12:37:58

Ok, si je résume tout ça :

- le noyau linux sait gérer les volumes HFS et HFS+. J'ai trouvé ça dans la doc du paquet hfsprogs :
"Le système de fichiers HFS+ utilisé par Apple Computer pour son Mac OS est
pris en charge par le noyau Linux. Apple fournit mkfs et fsck pour HFS+
avec le cœur Unix de son système d’exploitation, Darwin."
C'est pour ça qu'il n'y a pas de daemon, la prise en charge est native dans le noyau linux.

- pour ça, il faut que les volumes soient montés, ce qui est toujours le cas dans les environnements de bureaux, car quand on branche un volume externe, il est monté automatiquement par le système, et si c'est un disque interne, il faut le déclarer dans fstab

- effectivement, pas besoin des paquets hfsplus, hfsutils et hfsprogs pour ça (j'ai refait le test)

- par contre, en mode root, il faut donner les droits en lecture/écriture sur le disque monté, car par défaut, en général, on ne peut pas écrire sur le volume qui est en lecture seule du fait qu'on n'en est pas le propriétaire (enfin, informatiquement parlant !).

Dernière modification par Debeee (06-10-2019 19:45:25)

raleur · 06-10-2019 14:48:54

Debeee a écrit :

en mode root, il faut donner les droits en lecture/écriture sur le disque monté, car par défaut, en général, on ne peut pas écrire sur le volume qui est en lecture seule

Je ferai deux critiques à cette formulation.
1) Il ne faut pas confondre le montage d'un système de fichiers en lecture seule avec les permissions d'accès. Même root ne peut pas écrire dans un système de fichiers en lecture seule, cela s'applique à tous les utilisateurs indépendamment des permissions d'accès.
2) Les permissions qui vont bien peuvent être définies lors de la création du système de fichiers avec les options de mkfs.hfsplus, de sorte qu'il ne sera pas nécessaire de les modifier après le montage.

Debeee · 06-10-2019 19:42:36

Exact, j'ai corrigé mon baratin.
Après, le fait d'avoir un volume en lecture seule, à part les volumes "morts" style CD ou DVD, je pense qu'il doit pas y en avoir beaucoup. Quand un utilisateur rencontre un disque en lecture seule, c'est juste qu'il n'a pas les bons droits.

raleur · 07-10-2019 08:59:29

Ça peut aussi arriver quand le système de fichiers est endommagé ou n'a pas été démonté correctement, notamment avec les volumes NTFS utilisés par un système Windows mis en hibernation ou arrêté avec l'option de démarrage rapide activée.

Debian-facile

#1 10-09-2019 09:03:14

avantage désavantege d'un /home séparé

#2 10-09-2019 09:55:13

Re : avantage désavantege d'un /home séparé

#3 10-09-2019 10:15:17

Re : avantage désavantege d'un /home séparé

#4 10-09-2019 10:21:11

Re : avantage désavantege d'un /home séparé

#5 10-09-2019 10:40:02

Re : avantage désavantege d'un /home séparé

#6 10-09-2019 23:50:25

Re : avantage désavantege d'un /home séparé

#7 11-09-2019 09:32:22

Re : avantage désavantege d'un /home séparé

#8 11-09-2019 14:16:51

Re : avantage désavantege d'un /home séparé

#9 11-09-2019 21:13:11

Re : avantage désavantege d'un /home séparé

#10 11-09-2019 22:27:59

Re : avantage désavantege d'un /home séparé

#11 28-09-2019 20:19:21

Re : avantage désavantege d'un /home séparé

#12 30-09-2019 20:54:50

Re : avantage désavantege d'un /home séparé

#13 01-10-2019 09:39:18

Re : avantage désavantege d'un /home séparé

#14 01-10-2019 13:36:22

Re : avantage désavantege d'un /home séparé

#15 02-10-2019 13:45:54

Re : avantage désavantege d'un /home séparé

#16 03-10-2019 06:59:08

Re : avantage désavantege d'un /home séparé

#17 03-10-2019 09:05:54

Re : avantage désavantege d'un /home séparé

#18 03-10-2019 09:35:36

Re : avantage désavantege d'un /home séparé

#19 03-10-2019 09:44:14

Re : avantage désavantege d'un /home séparé

#20 04-10-2019 14:53:12

Re : avantage désavantege d'un /home séparé

#21 05-10-2019 13:42:11

Re : avantage désavantege d'un /home séparé

#22 06-10-2019 12:37:58

Re : avantage désavantege d'un /home séparé

#23 06-10-2019 14:48:54

Re : avantage désavantege d'un /home séparé

#24 06-10-2019 19:42:36

Re : avantage désavantege d'un /home séparé

#25 07-10-2019 08:59:29

Re : avantage désavantege d'un /home séparé

Pied de page des forums