4 votos

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

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.

Antecedentes:

Después de montar con éxito el directorio a través de SMB y de utilizarlo durante algún tiempo, parece que el directorio se desmonta por sí mismo. Cuando esto ocurre, no puedo volver a montar el directorio hasta que reinicio el sistema.

Si no reinicio el sistema y utilizo el cuadro de diálogo "Conectar con el 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 intento hacer lo mismo con un directorio principal (que es el directorio root del servidor), la conexión parece tener éxito y me pide que "seleccione los volúmenes que desea montar en 'xyz.nombre.servidor':" con una lista de directorios. El directorio que monté previamente (que se autodesmontó) aparece en la lista, pero está fantasma y por lo tanto no se puede seleccionar.

Al conectarse por SSH al servidor, no parece haber ningún problema para acceder al directorio.

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

Además, al intentar reconectarse en este escenario, la consola informa del siguiente problema:

"30/10/2014 11:48:20.520 am NetAuthSysAgent[3346]: smb_mount: mount failed to my.server.com/mydirectory, syserr = File exists"

Preguntas:

i) ¿Cuál es la causa de que se desmonte el directorio/volumen?

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

iii) Si se produce un desmontaje automático, ¿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)

Kernel versión 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
//josh@example.com/josh                          10568950416 10486471008   82479408   100%         0 18446744073709551615    0%   /Volumes/josh
//josh@example.com/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
//josh@example.com/josh                          10568950416 10466951592  101998824   100%         0 18446744073709551615    0%   /Volumes/josh
//josh@example.com/semantic                      12682735248  7708953400 4973781848    61%         0 18446744073709551615    0%   /Volumes/semantic

Observaciones:

Los directorios montados siguen apareciendo en /Volumes cuando se ven desde el terminal, (es decir, 'ls /Volumes'), aunque no siempre es así, 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 desde Matlab, que ya estaba dentro de un subdirectorio de este directorio (su directorio de trabajo). Si luego me muevo fuera del directorio en Matlab (digamos, a mi directorio personal), no puedo volver a él a través del comando 'cd', sino que tengo que pulsar el botón de retroceso dentro de la barra de herramientas de navegación de archivos y entonces todo es accesible de nuevo desde dentro de Matlab.

1voto

Neil McKeown Puntos 348

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

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

Prueba con diskutil umount /Volumes/josh y debería funcionar.

El error "El archivo existe" aparece porque el punto de montaje que quiere utilizar ya está presente. Parece que el disco no está realmente desmontado, sólo que Finder no puede verlo. Por eso Matlab puede seguir accediendo a los archivos que hay en él.

0voto

zomgdavidbowie Puntos 43

Según el Sitio de Red Hat no admiten el uso de recursos compartidos SMB mediante el Finder de OS X. Parece que todavía se puede llegar a él usando la Terminal, por lo que podría ser una solución por ahora.

En cuanto a la desconexión aleatoria: Parece que el recurso compartido se conectará inicialmente, y luego se desconectará cuando se dé cuenta de que está en el entorno Mac. Me parece que el recurso compartido no se desmonta correctamente, y es por eso que usted no sería capaz de volver a conectarse a él. En realidad sigue ahí, sólo que no es visible en el Finder.

Si se desmonta manualmente el recurso compartido utilizando el Terminal, espero que no aparezca en gris si se intenta conectar a él de nuevo.

Una solución: Dependiendo de cómo se haya configurado el servidor de Red Hat, deberías ser capaz de hacer FTP en él. Mac tiene unas cuantas interfaces gráficas de FTP que puede probar, o utilizar la función de la Terminal ftp comando.

0voto

Rich Puntos 2429

¿Qué está causando el desmontaje del directorio/volumen?

Lo más probable es que se trate de una inestabilidad en la conexión a la red que podría verse amplificada por el uso de la Automatic configuración que podría cambiar de Ethernet a Aeropuerto tratando de mantener su conectividad de red.

Para validar esta hipótesis, utilice:

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 el cable
  • cambiar el puerto del conmutador
  • pregunte a su administrador de red
  • ...

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

No se puede si el unmount no ha terminado correctamente. Alguna información de estado dentro de su extensión de kernel SMB está corrompida (medio modificada) y no puede ser arreglada de otra manera que no sea la terminación correcta de los pendientes unmount . Si tu conexión se rompió, Conozco una forma única de terminar un SMB pendiente unmount : shutdown de Mac OS X (probé una kextunload lo que lleva a un fracaso total).

Hay que evitar absolutamente que se produzca ese desmontaje pendiente.

0voto

SpaceGoebi Puntos 1

La respuesta de miken32 no me funcionó, pero me puso en el camino correcto. Mi problema se resolvió después de desmontar todo en el servidor en cuestión (en su caso "ejemplo.com").

Así que, usando su caso, diskutil umount /Volumes/josh no es suficiente, porque /Volumes/semantic sigue siendo. Debes desmontar ese también. Después de eso, volver a montar debería funcionar (al menos a mí me funcionó).

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

umount //josh@example.com/josh

y

umount //josh@example.com/semantic

0voto

Macuser Puntos 1

Tengo el mismo problema, lo tuve en 10.6.8 y ahora en 10.11. La causa es doble: por un lado, se supone que el recurso compartido se desmonta (por ejemplo, en el sueño), pero no puede porque está siendo (marcado como) utilizado, por lo que muere y lo que queda es una carpeta en /Volumes que a veces podría simplemente eliminar y luego volver a montar. Sin embargo, en 10.11 es invisible en el Finder DESPUÉS de que el recurso compartido muere (ver las preferencias del Finder, dicen que el Finder sólo muestra los recursos compartidos activos.

Para el segundo, la bandera de que los archivos están en uso es establecida por MatLab. Algunas veces puede eliminarlos mediante el comando de MatLab fclose all y cd a algún otro lugar para liberar el recurso compartido, algunas veces realmente se usan los archivos (editando .m scriptdel recurso compartido). Pero muchas veces después de un periodo de inactividad se queda en un punto muerto: umount y diskutil unmount no puede liberar la acción porque "Recurso ocupado" y MatLab no puede liberar sus banderas porque la acción ha desaparecido.

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

AppleAyuda.com

AppleAyuda es una comunidad de usuarios de los productos de Apple en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X