¿Cómo puedo usar recursos compartidos SMB en Mavericks?

Parece que hay diferentes problemas y soluciones a este problema dando vueltas:

  1. Arreglar el cambio de SMB a cifs
  2. No poder acceder a los recursos compartidos de OS X desde Windows
  3. Todo tipo de problemas con SMB y Mavericks en Apple

Mi problema es como en el primer enlace: tengo un servidor SMB Raspberry Pi (Linux). Sirve archivos a mi MBP ejecutando Mavericks. Sin embargo, no puedo conectarme al Pi. El registro de la consola dice:

30.10.13 21:50:53,422 NetAuthSysAgent[6632]: smb_mount: mount failed to raspberrypi/MyShare, syserr = File exists

Cuando voy a /Volumesun shell y hago un ls, obtengo esto:

user@mac:/Volumes $ ls -l
ls: MyShare: Invalid argument
total 8
lrwxr-xr-x  1 root  admin  1 28 Okt 21:39 M4 -> /
user@mac:/Volumes $

Entonces, mi disco duro principal M4 está visible, el recurso compartido produce un argumento no válido. Ya reinicié mi Mac tres veces.

¿Como puedo resolver esto?

Por interés, ¿hay alguna razón por la que esté usando SMB sobre AFP en su RPi?
Sí, también tengo máquinas con Windows en mi red. :)
¿Consideraría usar SMB en Windows y AFP en Mac? :)
Oh, bueno... ¡Tal vez lo intente, solo porque nunca usé AFP! Sin embargo, después del cuarto reinicio todo funciona, ¡por ahora! Estaré atento a este problema e intentaré formular una respuesta útil.
Sí, acabo de configurar AFP y funciona muy bien. ¿Quieres escribir una respuesta?
¡Hecho! :) He agregado más información sobre cómo configurar Netatalk en caso de que alguien más encuentre esta pregunta.

Respuestas (2)

Si no puede hacer que SMB funcione, pruebe con AFP. Puede ejecutar ambos en paralelo y usar SMB en su Windows y AFP en OS X.

Para configurar AFP en su Raspberry Pi, puede usar el siguiente comando:

sudo apt-get install netatalk

Esto instalará Netatalk en su RPi, y luego de una instalación exitosa, el RPi debería mostrarse automáticamente en la sección Compartido en Finder y en el vecindario de Red (⌘⇧K):

De lo contrario, puede conectarse manualmente presionando ⌘K y escribiendo afp://seguido de la dirección IP de su RPi.

Después de un mes de uso, puedo decir que funciona bien. Pero en realidad parece mejor nombrar el servidor AFP de manera diferente al servidor SMB. Cambié el nombre de netbios en smb.conf, pero también puede cambiar el nombre en afp_signature.conf de netatalk.

Esta publicación resolvió mi problema. Intente configurar manualmente la unidad de transmisión máxima en la configuración de su sistema>Redes>WLAN/Ethernet>Avanzado>Hardware>MTU personalizada de 1320.

Mi problema también fue un problema de retraso creciente. Una vez que monté las cosas, todo funcionó normalmente. Aparentemente, la MTU predeterminada es demasiado alta. Bajar manualmente esto hizo que el montaje de smb comparta un proceso mucho más rápido.

La publicación original que pegaré aquí para mantener stackexchange autónomo:

Me embarqué en una misión de prueba... Con Wireshark logré ver que los paquetes se descartaban al transferirlos a través de la red: no existían los mismos patrones con la misma transferencia inalámbrica o la misma transferencia por cable a un servidor de Windows.

Así que busqué un poco en Google y se me ocurrió el siguiente comando:

ping -c 1 -D -s 1500 servidor smb

Básicamente, hace ping al servidor con una MTU de 1500, a lo que obtuve:

ping: enviar a: mensaje demasiado largo

Tenga en cuenta que también recibo este error en un servidor de Windows, pero lo que puede ser el problema es que cuando su software recibe esta respuesta, se supone que disminuye automáticamente la MTU hasta que encuentra la óptima para la transferencia de paquetes, algo que parece que Mavericks estar haciendo con los servidores de Windows pero no con los de Linux.

Entonces, usando el comando ping, puedo encontrar una MTU óptima para la transferencia:

ping -c 1 -D -s 1320 servidor smb

Ahora obtengo la respuesta:

min/avg/max/stddev de ida y vuelta = 0,829/0,829/0,829/0,000 ms

Tuve que perder el tiempo tratando de encontrar el nivel óptimo, pero te da una idea en la prueba. Después de esto tomo mi número y voy a:

Preferencias del sistema -> Red -> USB Ethernet -> Avanzado... -> Hardware -> Configurar: Manualmente -> MTU personalizado: 1320

Después de esto, desconecté mis recursos compartidos, los restablecí y luego intenté otra transferencia a mi servidor Linux. ¡Éxito! De acuerdo, no es lo que yo consideraría velocidad máxima, pero parece mejor reducir una transferencia de 5 GB de 8 horas a 30 minutos. Lo ha llevado de completamente inutilizable a tolerable.

No estoy completamente seguro de cuál es la raíz del problema, ya que no soy un experto en redes, ya que la reducción de MTU parece funcionar en un servidor de Windows y no en uno de Linux, y funcionó bien en versiones anteriores del sistema operativo. X, supongo que está relacionado con el controlador y/o la pila.

Por cierto, intenté actualizar a 10.9.1 a través de la descarga del desarrollador antes de probar esto, la actualización 10.9.1 no solucionó el problema para mí antes de ir a la solución de problemas.

¿Cómo puedo usar recursos compartidos SMB en Mavericks?
RespuestasAquíPolítica de privacidad1y, 0v