'Não Há Espaço Suficiente em Disco' no Mac: O Que Apagar Primeiro
O que apagar primeiro quando o macOS avisa que não há espaço suficiente em disco, na ordem dos gigabytes que cada passo realmente devolve.
Mais guias como este, por enquanto, só estão disponíveis em inglês. Ver todos os artigos
Essa é a versão desse problema em que você não tem tempo para ler uma explicação longa — algo está bloqueado agora mesmo e você precisa de espaço de volta nos próximos cinco minutos. Aqui está a ordem que realmente funciona, mais rápida e de maior retorno primeiro.
Primeiro, veja o tamanho do problema
df -h /
A coluna Avail é o que você tem para trabalhar. O próprio macOS fica desconfortável abaixo de
aproximadamente 10% livre no volume inteiro — se você está perto dessa linha, os passos abaixo, na
ordem, devem te tirar dela rapidamente.
Passo 1: Esvazie a Lixeira de verdade
O motivo mais comum de “eu apaguei coisas mas ainda não tenho espaço” — apagar um arquivo move ele para a Lixeira, que ainda conta contra o seu espaço usado até a Lixeira ser realmente esvaziada:
# Esvazia a Lixeira pelo shell, incluindo arquivos grandes para os quais
# o "Esvaziar Lixeira" do próprio macOS às vezes pede confirmação extra
rm -rf ~/.Trash/*
Se você apagou um arquivo grande especificamente para liberar espaço e não esvaziou a Lixeira depois, esse passo sozinho costuma resolver o problema todo.
Passo 2: Pasta Downloads, ordenada por tamanho
O segundo ofensor mais comum — instaladores, arquivos .dmg, e downloads grandes que as pessoas
esquecem completamente depois de usar uma vez:
du -sh ~/Downloads/* 2>/dev/null | sort -hr | head -20
Arquivos instaladores .dmg e .pkg são o culpado clássico aqui — você instala o app, a imagem de
disco fica lá para sempre depois, totalmente redundante já que o app agora está instalado. Seguro
para apagar qualquer instalador de software que você já configurou.
Passo 3: Snapshots locais do Time Machine
Se você tem um laptop, é bem provável que o macOS tenha snapshots locais a cada hora consumindo espaço que você não sabia — isso pode ser 10–40 GB que você recupera em menos de um minuto:
tmutil thinlocalsnapshots / 10000000000 4
Veja a explicação completa do que isso faz e quando é seguro se quiser o detalhe — a versão curta é: seguro, a menos que snapshots locais sejam o seu único backup, o que para a maioria das pessoas não é o caso.
Passo 4: ~/Library/Caches, por completo
Se os passos 1–3 não liberaram espaço suficiente, esse é o próximo movimento de maior retorno e menor risco — o próprio local designado pela Apple exatamente para esse tipo de dado descartável:
rm -rf ~/Library/Caches/*
A explicação completa de por que isso é seguro, e o pequeno número de exceções que valem a pena conhecer, está em o guia dedicado a essa pasta — mas para uma emergência, esse comando é seguro para rodar sem ler mais nada antes.
Passo 5: Se você é desenvolvedor, os três grandes
Só esses três costumam somar 50–150 GB combinados numa máquina que já fez qualquer quantidade de desenvolvimento em iOS, Docker ou Node:
rm -rf ~/Library/Developer/Xcode/DerivedData/*
docker system prune -a --volumes # só se você tiver o Docker instalado e rodando
find ~ -name "node_modules" -type d -prune -exec du -sh {} \; 2>/dev/null | sort -hr | head -10
Cada um tem um guia dedicado com o detalhe completo: DerivedData, Docker, node_modules.
Se nada disso foi suficiente
Nesse ponto, o espaço restante quase certamente está ou nos seus arquivos de verdade — biblioteca do Photos, Music, Documents — que este artigo deliberadamente não toca, já que isso é o seu dado, não cache, e você deveria decidir o que fazer com isso de forma deliberada, e não sob pressão de tempo. Ou está em “System Data”, o bloco genérico da Apple coberto em um guia separado, que exige mais investigação do que uma passagem de emergência de cinco minutos consegue cobrir.
Por que isso continua acontecendo
Nenhum dos cinco passos acima é uma correção definitiva — cada um deles se reabastece. Caches se regeneram conforme você usa os apps, a DerivedData se reenche no momento em que você compila, snapshots do Time Machine recomeçam a cada hora no momento em que você os apaga. A correção de emergência e a correção de verdade são coisas diferentes: este artigo te desbloqueia hoje; checar essas mesmas cinco categorias com regularidade, antes de qualquer uma delas chegar ao nível de “bloqueando uma exportação”, é o que evita precisar dele de novo no mês que vem.
O DevCruft, um app gratuito para Mac que estamos construindo, está sendo projetado para fazer essa checagem por você e mostrar essas cinco categorias continuamente. Ele ainda está em desenvolvimento; entre na lista de espera para saber quando for lançado.