10.14 Mojave Système qui prend trop de place

Statut
Ce sujet est fermé.
Passe les 2 commandes (séparément) :
Bloc de code:
sudo du -sh /Users/*
sudo du -sh ~/*
  • qui mesurent (en Gi) les dossiers de comptes dans les Utilisateurs > puis les sous-dossiers de ton dossier de compte moanaadventuretours5

Poste les retours.
 
Bloc de code:
Last login: Sat Feb  6 11:37:11 on console
Vairea-LHL:~ moanaadventuretours5$ sudo du -sh /Users/*
Password:
20K    /Users/Guest
4.0K    /Users/Shared
73G    /Users/moanaadventuretours5
Vairea-LHL:~ moanaadventuretours5$
 
Dernière édition par un modérateur:
Tout est dans ton dossier de compte. Mais tu n'as pas posté le retour de la seconde commande :
Bloc de code:
sudo du -sh ~/*
 
Bonjour,

J'ai un pb similaire. En effet j'avais des fichiers volumineux dans le dossier partagé mais après les avoir supprimés (et vidé la corbeille) l'espace système prenait toujours autant de place.

Voilà le résultat des commandes demandées :

diskutil list

Bloc de code:
/dev/disk0 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      GUID_partition_scheme                        *251.0 GB   disk0
   1:                        EFI EFI                     209.7 MB   disk0s1
   2:                 Apple_APFS Container disk1         250.8 GB   disk0s2

/dev/disk1 (synthesized):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:      APFS Container Scheme -                      +250.8 GB   disk1
                                 Physical Store disk0s2
   1:                APFS Volume ****                 246.1 GB   disk1s1
   2:                APFS Volume Preboot                 24.2 MB    disk1s2
   3:                APFS Volume Recovery                507.6 MB   disk1s3
   4:                APFS Volume VM                      2.1 GB     disk1s4

diskutil verifyVolume disk1

Bloc de code:
Started file system verification on disk1
Verifying storage system
Using live mode
Performing fsck_apfs -n -x -l /dev/disk0s2
Checking the container superblock
Checking the EFI jumpstart record
Checking the space manager
Checking the space manager free queue trees
Checking the object map
Checking volume
Checking the APFS volume superblock
Th volume **** was formatted by hfs_convert (748.77.8) and lastmodified by apfs_kext (945.275.9)
Checking the object map
Checking the snapshot metadata tree
Checking the snapshot metadata
Checking snapshot 1 of 1
error: btn: invalid key order (1) oid 632523 / oxid 0
Snapshot is invalid
The volume /dev/disk0s2 could not be verified completely
Storage system check exit code is 0
Finished file system verification on disk1

On dirait que j'ai un pb ici


Merci.
 
Dernière édition par un modérateur:
Bonjour TheZardoz

Ces lignes -->
Bloc de code:
Checking snapshot 1 of 1
error: btn: invalid key order (1) oid 632523 / oxid 0
Snapshot is invalid
  • montrent qu'il existe un snapshot corrompu associé au volume de démarrage principal. Un snapshot est un instantané apfs qui archive un état passé du volume > en retenant comme occupés tous les blocs porteurs des écritures des fichiers correspontants. Même si tu supprimes ensuite des masses de ces fichiers => ils sont désindexés du catalogue des fichiers de l'apfs > mais les blocs portant leurs écritures ne sont pas libérés mais restent verrouillés à l'état occupé.
  • un snapshot valide est identifié par la date de sa prise > et est alors supprimable pour libérer les blocs correspondants. Un snapshot corrompu n'a pas de date qui l'identifie > et reste alors insuppressible. C'est une sorte d'erreur non corrigible dans l'apfs. Tu es dans ce cas de figure. C'est ce qui explique la sur-occupation du volume et le fait que tu ne puisses pas la faire baisser.
  • la seule solution dans ce cas consiste à cloner les volumes du Conteneur => dans le Conteneur d'un DDE USB. Démarrer sur le clone. Supprimer / recréer l'apfs interne. Cloner à rebours le clone dans le nouveau Conteneur interne. Ce qui se trouve cloné puis rétro-cloné par ce procédé => c'est uniquement les fichiers catalogués du volume et non les blocs occupés d'écritures de fichiers du passé. Il importe donc en prévision du clonage de connaître la taille actuelle des fichiers catalogués.

Comme la commande de mesure des fichiers est dénaturée en cas d'activation du SIP (protocole de sécurisation) > passe la commande préalable :
Bloc de code:
csrutil status
  • qui affiche le statut du SIP

Poste le retour.
 
Merci pour la réponse rapide !

voilà la reponse de la commande
Bloc de code:
csrutil status
System Integrity Protection status: enabled
 
SIP activé (enabled).

----------

Pour désactiver le SIP > redémarre > les 2 touches ⌘R (cmd R) tenues pressées de l'écran noir => à la  = démarrage sur l'OS de secours. Tu obtiens un écran affichant une fenêtre de 4 Utilitaires macOS. Va à la barre de menus supérieure de l'écran > Menu Utilitaires > sous-menu : Terminal.

Lance-le et passe la commande :
Bloc de code:
csrutil disable
  • qui désactive le SIP

Cela fait > quitte le Terminal > va à : Menu  > Disque de démarrage > sélectionne **** (le nom de ton volume de démarrage) > redémarre dessus.

----------

De retour dans ta session > passe la commande (copier-coller) :
Bloc de code:
sudo find -x / -d 1 -regex '.*[^\.\].*' -exec sudo du -shx {} +
  • à validation > une demande de password s'affiche (commande sudo) --> tape ton mot-de-passe de session admin en aveugle - aucun caractère ne se montrant à la frappe - et revalide
  • la commande mesure (en Gi = gibibytes : base 2) les objets de 1er rang du volume de démarrage (fichiers ou dossiers / visibles ou cachés). Elle est très lente d'exécution : attends le retour de l'invite de commande terminée par ton nomcourt$ en signal de fin.

Poste le tableau dans une fenêtre de code.
 
voilà le résultat :
Bloc de code:
0B    /.HFS+ Private Directory Data
1,0K    /home
12G    /usr
515M    /.Spotlight-V100
1,0K    /net
24K    /.DS_Store
  0B    /.PKInstallSandboxManager-SystemSoftware
2,5M    /bin
  0B    /installer.failurerequests
  0B    /Network
1,0M    /sbin
  0B    /.file
  0B    /etc
  0B    /var
14G    /Library
12K    /MyPlayground.playground
  0B    /.Trashes
6,6G    /System
4,0K    /.fseventsd
6,1G    /private
39M    /.DocumentRevisions-V100
  0B    /.vol
43G    /Users

33G    /Applications
177M    /opt
4,5K    /dev
4,0K    /Telemetry
  0B    /Documents
  0B    /Volumes
  0B    /tmp
  0B    /cores


Maintenant la place prise par les applications est devenue grise et est comptée comme "système" ....
 
Je comptabilise 115,4 Gi = 124 Go de fichiers catalogués. Loin des 246 Go de blocs occupés. Il y a donc un espace occupé fantôme de 122 Go dû au snapshot corrompu.

- il te faut donc un DDE USB permettant de créer un Conteneur de 150 Go environ.​
 
Il faudra l'initialiser pour qu'il ait une table de partition GUID (requise pour créer une partition apfs) > et un Conteneur apfs de la taille voulue. Mais si tu as un DDE avec déjà une table GUID et un volume repartitionnable (format Mac OS étendu journalisé) => alors il est possible de créer une partition apfs sans supprimer le volume existant et ses données.

- bref : tout dépend du DDE disponible. Il faudra inspecter d'abord sa configuration.​
 
Statut
Ce sujet est fermé.