Como desmontar forçosamente o compartilhamento de rede preso no Mac OS X?

7

Não faz muito tempo, meu Xserve falhou (perda de energia) enquanto um iMac estava trabalhando com arquivos em um compartilhamento de rede específico (chamado "Work Share"). Este volume, "Work Share", está agora preso. Não pode ser visto na GUI, você só pode detectá-lo usando o Terminal. Mesmo após o ciclo de energia ao longo de vários dias, ls -a ainda mostra que está lá, mas não consigo desmontá-lo usando qualquer comando - nem mesmo como root no modo de usuário único.

Toda vez que tento desmontar esse volume (hdiutil, diskutil, umount), recebo a mensagem de que o recurso está ocupado (o que possivelmente não pode ser porque nada está sendo usado) e o código de erro 4915 simplesmente falha.

A questão é que quando montei o real "Work Share", ele é renomeado internamente como "Work Share-1", o que quebra todos os meus links e vários arquivos no compartilhamento. Se eu não posso desmontar o falso "Work Share", então esse computador seria inutilizável sem uma reformatação, eu imagino - e eu não quero que isso aconteça.

Eu tentei tudo o que posso imaginar - parece que o sudo não pode me salvar agora.

Alguma ideia de como desmontar este volume preso?

    
por Kyle Lowry 24.02.2011 / 00:18

4 respostas

8

Além de ver uma pasta com esse nome em / Volumes, como você sabe que o compartilhamento remoto ainda está montado? O mount ou diskutil list ainda mostra como montado? Se não, então o que você tem não é uma montagem presa, mas um diretório de ponto de montagem que foi deixado para trás depois que o compartilhamento remoto foi embora inesperadamente. Se houver arquivos nesse diretório, eles existirão em sua unidade de inicialização local e provavelmente foram escritos por qualquer processo que estivesse sendo executado no iMac que estivesse trabalhando com esse compartilhamento.

Se esse for o caso, você poderá corrigi-lo apenas movendo o diretório e os arquivos do lado esquerdo:

sudo mv /Volumes/Work\ Space ~/Desktop

... e, em seguida, monta novamente o seu compartilhamento remoto.

Mas se mount mostrar o compartilhamento remoto ainda montado, bem, esse tipo de estado não sobreviverá a uma reinicialização, então, a menos que você esteja em alguma situação em que não queira reinicializar, eu diria apenas reinicie o iMac.

    
por 24.02.2011 / 07:02
8

Primeiro, tente sudo umount -f YOURDEVICE , se não funcionar, exclua a entrada em /etc/mtab , se esse arquivo existir no MacOS. O arquivo normalmente deve ser atualizado automaticamente, mas talvez tenha sido corrompido.

Se a edição for impossível, exclua-a com rm -f . Deve ser recriado.

    
por 24.02.2011 / 01:27
4

Estou no Mac OS 10.12.2 Sierra e o acima não funcionou. O que funcionou foi:

  1. Em um terminal, corri sudo umount -Af -t nfs,smbfs
  2. Depois mudei para o diretório /Volumes ( cd /Volumes ) e removi as pastas de ponto de montagem residual. O (s) nome (s) da pasta será diferente dependendo do nome da (s) pasta (s) que você montou, mas minha pasta foi chamada Athena , por isso fiz sudo rm -rf Athena/ após verificar se a pasta estava vazia com ls Athena/ . Se você montou a pasta várias vezes, pode haver outras pastas residuais com nomes como Athena-1/ , Athena-2/ etc., que também devem ser removidas.
  3. Em seguida, tente se reconectar ao compartilhamento no Finder e ele deve ser bem-sucedido.

Eu também desabilitei "Connected Servers" nas preferências do Finder (não tenho certeza se isso teve algum efeito).

    
por 23.05.2017 / 19:28
0

Estou no Mac OS 10.13.6 High Sierra e as respostas anteriores não estavam funcionando para mim. No meu caso, eu criei uma montagem automática via /etc/fstab e a pasta no meu caso era chamada de Pandora e era de propriedade de root . O que funcionou para mim foi:

  1. No terminal, executei vi /etc/fstab e removi a linha com Pandora mount que queria excluir.
  2. Mac Rebooted
  3. Agora notei que a pasta Pandora não era mais de root , mas agora pertence a uma conta de usuário normal.
  4. Excluiu a pasta pelo terminal com rm -rf Pandora/
por 11.09.2018 / 09:17