Mac mini не може підключитися до мого корпоративного SMB-сервера. Працював кілька днів тому

Я працюю, і мій Mac mini перестав мати можливість підключатися до спільних папок корпоративного SMB.

Якщо я спробую Finder> Connect to Server (використовуючи URL-адресу, збережену в попередніх успішних з'єднаннях), macOS Sierra скаржиться на більш ніж марну "загальну помилку".

У своїх журналах консолей я не можу виявити помилки, пов’язані з samba (куди мені слід шукати?)

На тому ж поверсі є клонічні Mac міні-машини (мої колеги), і вони можуть без проблем підключитися до цього сервера.

Якщо я пінг цієї машини з мого командного рядка, я можу це прекрасно бачити.

Якщо я спробую це в командному рядку:

smbutil view smb://192.168.XXX.XXX/docs/

macOS Sierra дає це:

smbutil: server connection failed: No such file or directory

Якщо я спробую цей точний командний рядок на машині колеги, він просто перелічує спільні ресурси, що звисають із цього SMB-сервера ...

Будь-який натяк? Можливо, це щось пов’язане з тим, що якусь службу відключено помилково в моєму Mac mini?

У мене немає доступу до машини та конфігурації сервера Samba Server.

Я прочитав і гуглив багато сторінок навколо, і я більше ніж загубився.

У випадку, якщо це може бути корисним, я використовую MacPorts. Тут може здатися випадковою річ, але, можливо, я не знаю про якусь бібліотеку, яку я могла б встановити, яка може бути проблемою з офіційним клієнтом OS X SAMBA.

УСПІХ !!

Після 2-х місяців (помірного) нещастя я нарешті знайшов причину, по якій SMB не працював зі своїм Sierra Mac Mini.

TL; DR Причиною цього був встановлений кекс:

com.intel.kext.intelhaxm (6.0.1) 8FF2C637-0A5E-367E-B007-5B08655B1E8A <7 5 4 3 1>

Ви можете перевірити, чи встановлено він, за допомогою наступної команди зі звичайного терміналу:

kextstat | греп -ів яблуко

Якщо у вас є (і якщо у вас також виникають проблеми з підключенням SMB), ви можете видалити його, знову ввівши наступну команду зі звичайного терміналу (не потрібно завантажуватися в режимі однокористувача):

sudo /Library/Extensions/intelhaxm.kext/Contents/Resources/uninstall.sh

Дотримуйтесь інструкцій на екрані, ПОВЕРТАЖУЙТЕ , і ви закінчили :)

При цьому ви втратите апаратне прискорення всередині ваших емуляторів Android, але вони працюватимуть у режимі програмного рендерінгу. Не геніально, але це щось. Ви можете перевстановити HAXM у випадку, якщо вам дійсно знову потрібне апаратне прискорення для емуляторів Android (але будьте готові знову втратити підключення SMB (?)).

Довга відповідь:

Якщо ви використовуєте свій Sierra Mac для розробки програм для Android, ви, ймовірно, встановили типові модулі, необхідні для випадкових випадків (Android SDK, емулятори, драйвери тощо). Справа в тому, що "прискорювач Intel HAXM" - один із типових драйверів встановіть, якщо ви хочете належного апаратного прискорення ваших емуляторів для Android. Ну, мабуть, вірите чи ні, цей драйвер не сумісний із використанням SMB під macOS Sierra, принаймні з моїм MAC.

Підсистема Sierra SMB та HAXM, мабуть, не пов'язані між собою програмним забезпеченням, але, здається, вони якимось чином несумісні між ними. Якщо у вас проблеми з SMB, вам доведеться вирішити, яка з двох вам справді потрібна більше:

SMB або належні швидкі емулятори для розробки Android .

Я вибрав SMB :)

Дякую ВСЕМУ за це запитання, відповідаючи, коментуючи тощо ... спеціально Бретт, який через багато тижнів поставив мене за правильний результат.

У мене була така ж проблема (1025 відмов у відкритті smb-пристрою, syserr = Немає такого файлу чи каталогу) і, нарешті, відстежив його до /dev/nsmb0неправильно налаштованого пристрою через суперечливий кекс із дуже старого додатка стороннього розробника. Якщо ви cat /dev/nsmb0отримаєте "Пристрій не налаштовано", можливо, схожа проблема.

Щоб вирішити це питання, я переглянув усі кекси, що не належать Apple, і видаляв програми / кексти по одному, поки це не працювало. Мені довелося завантажуватися в режимі єдиного користувача (cmd + s під час завантаження), щоб видалити деякі з них.

Ви можете шукати через завантажені кексети, що не належать Apple, використовуючи kextstat | grep -iv apple. Ось приклад виводу для мене на робочу систему:

Index Refs Address            Size       Wired      Name (Version) UUID <Linked Against>
   82    0 0xffffff7f8284c000 0x7000     0x7000     net.sf.tuntaposx.tap (1.0) 23FDB715-3D0D-3A26-ACBA-E3794C231CB7 <7 5 4 1>
   83    0 0xffffff7f82853000 0x7000     0x7000     net.sf.tuntaposx.tun (1.0) 95DD963D-E23D-3B0F-8DE8-A4D2F6BFA5CC <7 5 4 1>
   87    3 0xffffff7f8287c000 0x63000    0x63000    org.virtualbox.kext.VBoxDrv (5.0.28) 4ED2DD49-255E-37C8-A0B8-2556670B17B1 <7 5 4 3 1>
  144    0 0xffffff7f8363e000 0x7000     0x7000     com.zerotier.tap (1.0) 8BA59C0A-B3A7-3418-BFF5-B4914CE7734A <7 5 4 1>
  146    0 0xffffff7f83645000 0x8000     0x8000     org.virtualbox.kext.VBoxUSB (5.0.28) E7605ACF-20E3-3016-94E2-A6013CD9260F <145 87 40 7 5 4 3 1>
  151    0 0xffffff7f8366f000 0x5000     0x5000     org.virtualbox.kext.VBoxNetFlt (5.0.28) 89C23056-9027-33DB-852A-429BFA00D6DE <87 7 5 4 3 1>
  152    0 0xffffff7f83674000 0x6000     0x6000     org.virtualbox.kext.VBoxNetAdp (5.0.28) 1A767D65-6674-3A9F-B305-DAA197F109CC <87 5 4 1>

Ви можете вивантажити кексти за іменем файлу за допомогою:

kextunload /System/Library/Extensions/KextName.kext

або для назви пакета:

kextunload -b com.example.kext.name

Ви одночасно підключені до будь-яких інших акцій SMB? Я сьогодні повідомив Apple про помилку щодо macOS Sierra, згідно з яким, якщо я підключуюся до іншої SMB-спільної мережі на іншому сервері, при спробі підключення до другого він використовуватиме оригінальну IP-адресу та шлях спільного доступу з нового сервера.

Наприклад

1. Уже підключено до smb: //192.168.0.2/share1
2. Спроба підключитися до smb: //192.168.0.3/share2
3. Аналіз пакетів показує, що macOS намагається підключитися до smb: //192.168.0.2/share2, якого не існує.

Єдине обхідне рішення, яке я придумав, - це або підключитися до відключення від першого сервера, перш ніж спробувати з'єднання на другому. Однак це означає, що одночасно можна відкрити лише одне підключення SMB.

Трохи кращим рішенням було використання імені хоста для сервера замість IP-адреси. Це, здавалося, дозволило мені без проблем підключитися до другого SMB-сервера. Якщо ви не знаєте імені хоста, його можна отримати, відкривши термінал і ввівши наступну команду.

host <ip_address>

Сподіваюсь, це допомагає.

Редагувати - я вважав, що варто згадати, що ця проблема, мабуть, стосується всіх клієнтів, які перейшли до Сьєрри.