SMB: se desmonta automáticamente y no se puede volver a montar sin reiniciar

4

Tengo un problema recurrente con el montaje / desmontaje de directorios remotos a través de SMB, sin embargo, no sé qué desencadena el problema ni cómo resolverlo.

Background:

Después de montar con éxito el directorio a través de SMB y algún tiempo de uso, el directorio parece desmontarse por sí solo. Cuando esto sucede, no puedo volver a montar el directorio hasta que reinicie mi sistema.

Si no reinicio el sistema y utilizo el cuadro de diálogo "Conectar al servidor" para intentar montar el directorio a través de SMB, el cuadro de diálogo desaparece como si la conexión fuera exitosa, sin embargo no se monta nada.

Si trato de hacer lo mismo con un directorio principal (que es el directorio raíz del servidor), la conexión parece tener éxito y me indica que "Seleccione los volúmenes que desea montar en 'xyz.server .name ': "con una lista de directorios. El directorio que monté anteriormente (que se desmontó automáticamente) está en la lista, pero está fantasma y, por lo tanto, no se puede seleccionar.

Cuando se inserta SSH en el servidor, no parece haber ningún problema para acceder al directorio.

Este problema también ocurre con otros directorios remotos (aunque no he podido probarlo en otro servidor).

Además, al intentar volver a conectarse en este escenario, la Consola informa el siguiente problema:

"30/10/2014 11: 48: 20.520 am NetAuthSysAgent [3346]: smb_mount: el montaje falló en my.server.com/mydirectory, syserr = el archivo existe"

Preguntas :

i) ¿Qué está causando que el directorio / volumen se desmonte?

ii) ¿Cómo puedo evitar que ocurra el desmontaje automático?

iii) Si se desmonta automáticamente, ¿cómo puedo volver a montar el directorio sin reiniciar?

Detalles del sistema:

OS X 10.9.5

Retina, 15 pulgadas, principios de 2013

Detalles del servidor:

Red Hat Enterprise Linux Server versión 5.11 (Tikanga)

Versión del kernel 2.6.18-371.8.1.el5

Salida de df:

Antes del problema:

Filesystem                                        512-blocks        Used  Available Capacity   iused      ifree %iused  Mounted on
/dev/disk0s2                                       975425848   899360656   75553192    93% 112484080    9444149   92%   /
devfs                                                    371         371          0   100%       644          0  100%   /dev
map -hosts                                                 0           0          0   100%         0          0  100%   /net
map auto_home                                              0           0          0   100%         0          0  100%   /home
//[email protected]/josh                          10568950416 10486471008   82479408   100%         0 18446744073709551615    0%   /Volumes/josh
//[email protected]/semantic                      12682735248  7708953400 4973781848    61%         0 18446744073709551615    0%   /Volumes/semantic

Después del problema:

Filesystem                                        512-blocks        Used  Available Capacity   iused      ifree %iused  Mounted on
/dev/disk0s2                                       975425848   899350976   75562872    93% 112482870    9445359   92%   /
devfs                                                    373         373          0   100%       648          0  100%   /dev
map -hosts                                                 0           0          0   100%         0          0  100%   /net
map auto_home                                              0           0          0   100%         0          0  100%   /home
//[email protected]/josh                          10568950416 10466951592  101998824   100%         0 18446744073709551615    0%   /Volumes/josh
//[email protected]/semantic                      12682735248  7708953400 4973781848    61%         0 18446744073709551615    0%   /Volumes/semantic

Observaciones:

Los directorios montados aún están listados en / Volúmenes cuando se ven desde el terminal, (es decir, 'ls / Volumes'), aunque no siempre es el caso, pero ambos directorios son inaccesibles. No son visibles en el Finder en absoluto.

Sin embargo, todavía puedo acceder al contenido de uno de los directorios de Matlab, que ya estaba dentro de un subdirectorio de este directorio (su directorio de trabajo). Si luego me muevo fuera del directorio en Matlab (por ejemplo, a mi directorio de inicio), no puedo regresar a él a través del comando 'cd', sino que debo presionar el botón Atrás dentro de la barra de herramientas de navegación de archivos y luego todo es accesible de nuevo desde dentro de Matlab.

    
pregunta Josh 30.10.2014 - 02:27

5 respuestas

1

Voy a responder a la pregunta 3. No estoy seguro de que el resto se pueda diagnosticar fácilmente.

"Si se desmonta automáticamente, ¿cómo puedo volver a montar el directorio sin reiniciar?"

Prueba diskutil umount /Volumes/josh y debería hacer el truco.

El error "El archivo existe" se está mostrando porque el punto de montaje que quiere usar ya está presente. Parece que el disco no está desmontado, solo que el Finder no puede verlo. Esta es la razón por la que Matlab todavía puede acceder a los archivos en él.

    
respondido por el miken32 07.11.2014 - 22:47
0

Según Red Hat site , no admiten el uso compartido de SMB mediante el OS X Finder. Parece que todavía puedes obtenerlo usando la Terminal, por lo que podría ser una solución por el momento.

En lo que respecta a la desconexión aleatoria: suena como que el recurso compartido se conectará inicialmente, y luego se vuelve loco después de darse cuenta de que está en el entorno Mac. Me parece que el recurso compartido no se desmonta correctamente, y por eso no podrías volver a conectarte. En realidad, todavía está allí, pero no es visible en el Finder.

Si tuviera que desmontar manualmente el recurso compartido utilizando la Terminal, esperaría que no estuviera en gris si intentara conectarse nuevamente.

Una solución: dependiendo de cómo se configuró el servidor de Red Hat, deberías poder enviar FTP en él. Mac tiene algunas GUI de FTP que puedes probar o usar el comando ftp de la Terminal.

    
respondido por el zomgdavidbowie 07.11.2014 - 21:05
0
  

¿Qué está causando que se desmonte el directorio / volumen?

Probablemente sea una inestabilidad de conexión de red que podría amplificarse con el uso de la configuración Automatic que podría cambiar de Ethernet a Aeropuerto tratando de mantener su conectividad de red.

Para validar esta hipótesis, use:

netstat -I
ping -c 90 -i 10 your_SMB_server
tail -f /var/log/system.log
...
  

¿Cómo puedo evitar que se produzca el desmontaje automático?

Si se confirma este problema de red, entonces arréglalo :):

  • cambiar cable
  • cambiar puerto de conmutador
  • pregunte a su administrador de red
  • ...
  

Si se produce un desmontaje automático, ¿cómo puedo volver a montar el directorio sin   reiniciando?

No puedes si el unmount no terminó correctamente. Alguna información de estado dentro de la extensión del kernel SMB está dañada (la mitad modificada) y no se puede arreglar de ninguna otra forma que no sea la terminación correcta del unmount pendiente. Si tu conexión se rompió, Conozco una manera única de terminar un SMB pendiente unmount : shutdown de Mac OS X (probé un kextunload que llevó a una falla total).

Debe evitar absolutamente que se desate este pendiente pendiente.

    
respondido por el daniel Azuelos 10.11.2014 - 14:01
0

La respuesta de miken32 no funcionó para mí, pero me puso en el camino correcto. Mi problema se resolvió después de desmontar todos los recursos compartidos en el servidor en cuestión (en su caso, "example.com").

Entonces, usar su caso, diskutil umount /Volumes/josh no es suficiente, porque /Volumes/semantic aún permanece. Usted debe desmontar ese, también. Después de eso, volver a montar debería funcionar (lo hizo al menos para mí).

Por cierto, no tienes que usar diskutil, en su lugar puedes ejecutar

umount //[email protected]/josh

y

umount //[email protected]/semantic
    
respondido por el SpaceGoebi 09.06.2015 - 10:52
0

Tengo el mismo problema, lo tenía en 10.6.8 y ahora en 10.11. La causa es doble: por un lado, se supone que se desmonta compartir (p. Ej., En modo de espera), pero no se puede porque se está (marcando como) utilizado, por lo que muere y lo que queda es una carpeta en / Volúmenes que a veces solo se puede eliminar y luego volver a montar. Sin embargo, en 10.11 es invisible en el Finder DESPUÉS de que el recurso compartido muera (consulte las preferencias del Finder, dicen que el Finder solo muestra los recursos activos).

Para el segundo, MatLab establece el indicador de que los archivos están en uso. Algunas veces puede eliminarlos mediante el comando MatLab fclose all y cd a otro lugar para liberar el recurso compartido, algunas veces realmente usa archivos (editando el script .m desde el recurso compartido). Pero a menudo, después de un período de inactividad, se queda en un bloqueo: umount y diskutil unmount no pueden liberar el recurso compartido porque "Resource busy" y MatLab no pueden liberar sus marcas porque el recurso compartido ya no existe.

Utilizo macfusion, por lo tanto, hay un mecanismo para que el recurso compartido muera cuando sshfs pierde la conexión con el servidor. De estos tres: Finder, MatLab y fusible, yo diría que MatLab es malo, ya que otros programas como BBedit nunca bloquean la parte de una manera tan mortal. A menudo solo puedo volver a montar después de salir de MatLab.

    
respondido por el Macuser 11.07.2016 - 22:44

Lea otras preguntas en las etiquetas