macOS Tahoe 26.4 сломал SMB-резервное копирование Time Machine: исправление nsmb.conf до версии 26.5

Если вы установили macOS Tahoe 26.4 в конце марта 2026 года и ваше резервное копирование Time Machine на NAS Synology, QNAP, UGREEN, TrueNAS или Asustor внезапно перестало работать, вы не одиноки. Релиз Apple 26.4 незаметно ужесточил настройки SMB-подписи по умолчанию, и это изменение нарушило подключение Time Machine практически ко всем сетевым накопителям сторонних производителей на рынке. Патч 26.4.1, выпущенный 9 апреля, исправил несколько ошибок, но не затронул регрессию SMB в Time Machine.

Хорошая новость: существует известное обходное решение, которое вы можете применить уже сегодня вечером, и Apple уже исправила поведение в macOS 26.5 бета 4 (сборка 25F5068a, распространённая 27 апреля 2026 года). Плохая новость: публичный выпуск 26.5 ожидается не раньше конца мая, незадолго до WWDC 2026, которая начнётся 8 июня. Это означает, что большинство владельцев NAS несколько недель будут без работающего резервного копирования, если не вмешаются вручную.

В этом руководстве подробно объясняется, что изменилось внутри системы, описывается обходное решение через /etc/nsmb.conf с точным текстом для вставки, обобщается статус каждого крупного производителя NAS, оцениваются компромиссы в части безопасности при ослаблении SMB-подписи в домашней или офисной локальной сети, а также предлагаются более безопасные промежуточные стратегии резервного копирования на время ожидания. К концу руководства у вас снова будет работающее резервное копирование с чётким пониманием того, чем вы поступились, и знанием, как отменить изменение сразу после выхода macOS 26.5.

Ключевые выводы

• Что сломалось: macOS Tahoe 26.4 по умолчанию сделал SMB-подпись обязательной для подключений Time Machine. Большинство сторонних NAS не анонсируют SMB-подпись так, как это требует macOS 26.4, поэтому SMB-сессия отклоняется ещё до того, как Time Machine может смонтировать sparsebundle.
• Затронутые производители: Synology DSM 7.2 и старше, QNAP QTS 5.1.x, UGREEN UGOS 1.x, Asustor ADM 4.x, TrueNAS SCALE 24.x по умолчанию и многие другие SMB-цели сторонних производителей. Time Machine между компьютерами macOS по SMB по-прежнему работает.
• Симптомы: «Time Machine не смог завершить резервное копирование», «операция не разрешена», циклические запросы учётных данных, sparsebundle монтируется, но сообщается как нечитаемый, попытки полного повторного резервного копирования, прерывающиеся в течение нескольких секунд.
• Решение: Создайте /etc/nsmb.conf с параметрами signing_required=no и protocol_vers_map=7 до обновления прошивки NAS или выхода macOS 26.5.
• Риск: Отключение SMB-подписи делает SMB-сессию уязвимой к MITM-атакам в локальной сети. Приемлемо в доверенной домашней локальной сети, менее приемлемо в общем офисном Wi-Fi или сетях коворкинга.
• Сроки исправления: Бета 4 macOS 26.5 предположительно устраняет регрессию. Публичный выпуск 26.5 ожидается в конце мая 2026 года до WWDC.

Что и когда сломалось

Apple выпустила macOS Tahoe 26.4 в конце марта 2026 года как второе функциональное обновление в цикле Tahoe. В примечаниях к выпуску были выделены улучшения Apple Intelligence, обновление приложения «Календарь» и длинный список исправлений безопасности. Среди этих исправлений безопасности было скрыто изменение SMB-клиента, встроенного в macOS, ужесточающее способ согласования SMB-сессий ядром системы. Apple не выделила это в заголовках примечаний к выпуску, однако практический эффект оказался немедленным для всех, чьим назначением Time Machine было сторонним NAS.

В течение 48 часов после выхода 26.4 ветка сообщества Apple с номером 256221835 начала собирать сообщения от владельцев Synology и QNAP с описанием одинаковых симптомов. В параллельной дискуссии на Hacker News (запись 46848699) накопились сотни ответов пользователей самых разных потребительских и полупрофессиональных NAS. Закономерность была неоспоримой: резервные копии, которые исправно создавались каждую ночь в течение многих лет, внезапно отказались инициализироваться при первой попытке после обновления до 26.4.

Apple выпустила 26.4.1 9 апреля 2026 года, чтобы устранить ряд не связанных регрессий: проблему с роумингом Wi-Fi и ошибку отображения в Mail. Проблема SMB в Time Machine не фигурировала в примечаниях к патчу 26.4.1, а тестирование подтвердило, что регрессия пережила точечный выпуск. Пользователи, рассчитывавшие на то, что 26.4.1 тихо восстановит прежнее поведение, были разочарованы, а тон ветки сообщества Apple сменился с «только у меня такое?» на «Apple должна это признать».

Более детальный обзор цикла выпуска 26.4 и других известных регрессий можно найти в нашем полном руководстве по обновлению macOS Tahoe 26.4 и 26.4.1.

Галерея симптомов

Регрессия SMB в Time Machine проявляется по-разному в зависимости от производителя NAS, версии прошивки и конфигурации Time Machine до обновления. Наиболее распространённые симптомы перечислены ниже приблизительно в том порядке, в котором они встречаются в сообщениях пользователей.

Time Machine не может инициализироваться при первом запланированном резервном копировании после обновления до 26.4. Значок Time Machine в строке меню крутится несколько секунд, затем появляется сообщение «Time Machine не смог завершить резервное копирование на [имя общего ресурса]». При открытии Time Machine в системных настройках назначение по-прежнему отображается как настроенное, однако следующая попытка резервного копирования завершается точно так же.

Циклические запросы учётных данных. macOS запрашивает имя пользователя и пароль для SMB-ресурса, принимает их и сразу же запрашивает повторно. Сохранение учётных данных в Связке ключей не помогает, поскольку сама SMB-сессия отклоняется на уровне ниже аутентификации.

«Операция не разрешена» или ошибка POSIX 1. Это наиболее распространённая строка ошибки в базовых журналах. Она возникает, потому что sparsebundle на NAS технически доступен, но macOS отказывается его монтировать: SMB-сессия была согласована или понижена без свойств подписи, которые теперь требует macOS 26.4.

Sparsebundle монтируется, но сообщается как нечитаемый. Небольшая часть пользователей наблюдает монтирование тома резервной копии в Finder, однако Time Machine сообщает, что том нельзя использовать. Обычно это происходит, когда общий ресурс согласовывает неподписанную сессию SMB1 или SMB2 в качестве запасного варианта, а macOS отказывается выполнять запись в неё.

Попытки полного повторного резервного копирования, прерывающиеся в течение нескольких секунд. Некоторые пользователи пытались «исправить» проблему, удалив назначение и добавив его заново в расчёте на то, что новое резервное копирование сработает. Вместо этого повторное резервное копирование согласовывает ту же неработающую SMB-сессию и прерывается почти немедленно, порой оставляя на NAS пустой sparsebundle-заглушку.

Записи в консольном журнале со ссылками на smbfs, signature mismatch или STATUS_ACCESS_DENIED. Если открыть Console.app, отфильтровать по smb и воспроизвести ошибку, появятся сообщения ядра о переговорах по подписи. Это явное доказательство изменения в подписи.

Если вы наблюдаете сразу несколько из перечисленных симптомов, вы почти наверняка столкнулись с регрессией SMB-подписи 26.4, а не с аппаратной неисправностью NAS, сетевой проблемой или повреждённым sparsebundle. Более широкую диагностику Time Machine независимо от уровня SMB охватывает полное руководство по устранению неполадок Time Machine.

Почему это сломалось: объяснение изменения SMB-подписи Apple

Чтобы понять, почему обходное решение работает, полезно разобраться, что такое SMB-подпись на самом деле и почему Apple решила изменить настройку по умолчанию в версии 26.4.

SMB-подпись — это функция протокола Server Message Block, который macOS использует для подключения к общим ресурсам Windows, серверам Samba или NAS. При включённой SMB-подписи каждый пакет, отправляемый клиентом серверу, содержит криптографическую подпись, производную от ключа сессии. Сервер проверяет подпись каждого пакета и аналогичным образом подписывает свои ответы. В результате злоумышленник в той же сети не может подделать содержимое файлов при передаче без нарушения подписи и разрыва соединения.

SMB-подпись существует с версии SMB1 и по умолчанию обязательна в SMB3 для многих рабочих нагрузок Windows. Согласование протокола между клиентом и сервером определяет, является ли подпись «не используемой», «включённой, но необязательной» или «обязательной». До macOS 26.4 SMB-клиент macOS охотно согласовывал неподписанную сессию, если сервер не требовал подписи — именно этот путь большинство потребительских NAS выбирали по соображениям производительности.

В версии 26.4 Apple изменила настройку по умолчанию: теперь клиент требует подписи сессии, если явно не указано иное. При подключении к NAS, который объявляет подпись доступной, но не обязательной, macOS теперь отказывается переходить в режим без подписи. Согласование сессии завершается ошибкой, монтирование SMB не выполняется, а Time Machine не имеет назначения для записи.

Почему Apple пошла на это? Изменение согласуется с многолетними усилиями отрасли по ужесточению SMB. Microsoft сделала подпись обязательной по умолчанию в Windows 11 24H2, сообщество SMB переходит на SMB 3.1.1 с обязательной подписью, а корпоративные клиенты Apple давно этого требовали. Модель угрозы со стороны программ-вымогателей включает злоумышленников, которые переходят от скомпрометированной конечной точки к общим файловым ресурсам и подделывают резервные файлы при передаче, — и SMB-подпись является одним из наиболее эффективных средств противодействия.

Проблема в том, что производители NAS не получили чёткого уведомления о прекращении поддержки. Устройства Synology, QNAP и UGREEN поставляются с доступной, но не обязательной подписью, чтобы к ним могли подключаться старые клиенты Windows и встраиваемые устройства. macOS 26.4 фактически требует от этих производителей изменить собственные настройки по умолчанию, что не является исправлением одним обновлением прошивки на большинстве платформ: это сломало бы других клиентов в той же сети.

Более широкий обзор стека SMB в macOS Tahoe и многих других способов отказа SMB-соединений доступен в полном руководстве по устранению неполадок SMB и NAS, охватывающем проблемы подключения вне Time Machine.

Исправление nsmb.conf, шаг за шагом

Наиболее чистое обходное решение — сообщить macOS о готовности принимать SMB-сессии без подписи для доверенных соединений. macOS читает файл конфигурации по пути /etc/nsmb.conf при каждой настройке SMB-сессии, и в нём можно установить глобальный флаг, возвращающий поведение до версии 26.4.

Перед началом — два предупреждения. Во-первых, это изменение распространяется на все SMB-соединения вашего Mac, а не только на Time Machine, поэтому убедитесь, что вас устраивает компромисс по безопасности, описанный далее в статье. Во-вторых, правки в /etc/nsmb.conf требуют прав администратора и должны выполняться с осторожностью: некорректный файл приведёт к сбоям SMB-соединений иными и менее очевидными способами.

Быстрое исправление: однострочная команда

Если вам нужно просто запустить резервное копирование до отхода ко сну и вы уверенно пользуетесь Terminal, следующая команда создаёт файл с необходимыми настройками за один раз. Откройте Terminal в папке «Программы» → «Утилиты» и вставьте команду точно. Вам будет предложено ввести пароль администратора.

sudo tee /etc/nsmb.conf >/dev/null <<'EOF'
[default]
signing_required=no
protocol_vers_map=7
EOF

Строка signing_required=no сообщает SMB-клиенту macOS, что подпись необязательна. Строка protocol_vers_map=7 — битовая маска, допускающая согласование SMB 1, SMB 2 и SMB 3, что соответствует устаревшим настройкам по умолчанию. На большинстве современных NAS фактически используются только SMB 2 и SMB 3, однако включение SMB 1 в маску предотвращает пограничный случай, при котором согласование завершается полным отказом без выбора протокола.

После выполнения команды отмонтируйте все текущие SMB-ресурсы в Finder, подождите десять секунд и снова подключитесь к ресурсу по имени. Следующая попытка резервного копирования Time Machine должна завершиться успехом.

Постоянное исправление: ручное редактирование /etc/nsmb.conf

Если вы предпочитаете сначала увидеть файл или планируете добавить серверные переопределения позже, создайте или отредактируйте файл в текстовом редакторе с помощью sudo. Используйте любой удобный редактор; nano входит в состав macOS и является наиболее дружелюбным вариантом для нечастых пользователей Terminal.

sudo nano /etc/nsmb.conf

Вставьте следующее содержимое, сохраните с помощью Control-O и Return, затем выйдите с помощью Control-X.

[default]
signing_required=no
protocol_vers_map=7

# Optional: target a specific NAS by hostname.
# Replace synology.local with your NAS hostname.
[synology.local]
signing_required=no

Раздел [default] применяется ко всем SMB-соединениям. Необязательный второй раздел переопределяет настройки для одного имени хоста — это удобно, если вы хотите ослабить подпись только для NAS и сохранить строгость для подключений к корпоративному файловому серверу.

Для тех, кому нужен более тонкий контроль, существует альтернативный подход с использованием списка свойств по пути /Library/Preferences/com.apple.NetworkAuthorization.plist или менее известного механизма serverMarkers.plist для пометки конкретных серверов как «устаревших» и обхода новой логики подписи. Этот подход более инвазивен и хуже документирован, чем nsmb.conf, поэтому рекомендуем его только в случае, если nsmb.conf не решает проблему для вашей конкретной комбинации прошивки NAS.

Проверка работоспособности исправления

После сохранения файла следующая SMB-сессия, согласованная вашим Mac, будет учитывать новые настройки по умолчанию. Чтобы убедиться в правильном чтении файла, выполните следующую однострочную команду в Terminal.

cat /etc/nsmb.conf

Вы должны увидеть именно то, что написали. Если файл пуст или содержит другой блок [default], возможно, осталась устаревшая копия от предыдущей попытки применить обходное решение.

Чтобы наблюдать за согласованием SMB в реальном времени, откройте Console.app, введите smb в поле поиска, затем запустите резервное копирование Time Machine или вручную подключите ресурс. Вы должны увидеть успешную установку сессии, за которой следует подключение к дереву по имени ресурса. Предыдущие сбои записывали ошибки подписи в тот же поток, и их отсутствие после применения исправления — явный признак того, что обходное решение сработало.

Чтобы подтвердить версию согласованного протокола SMB, откройте «Мониторинг системы», перейдите на вкладку «Сеть» и найдите соединение smbd. Также можно выполнить smbutil statshares -a в Terminal: команда выведет список всех активных SMB-ресурсов и согласованного диалекта SMB. Строка SMB_VERSION SMB_3_0_2 или выше с SIGNING_SUPPORTED TRUE означает, что подпись по-прежнему используется оппортунистически, хотя больше не является обязательной — это лучший из возможных результатов.

Как только Time Machine успешно завершит первое резервное копирование, можно оставить конфигурацию как есть до выхода macOS 26.5. Для отмены удалите /etc/nsmb.conf или измените signing_required=no на signing_required=yes и переподключите ресурс.

Статус по производителям NAS

Серьёзность регрессии и доступность исправления со стороны производителя варьируются в зависимости от платформы NAS. Ниже приведено актуальное состояние дел на начало мая 2026 года.

Synology DSM. В середине апреля 2026 года Synology выпустила DSM 7.2.2 обновление 4 с переключателем конфигурации для включения обязательной SMB-подписи на стороне сервера. Включение этого переключателя в «Панели управления» → «Файловые службы» → SMB → «Дополнительные параметры» восстанавливает работу Time Machine без обходного решения nsmb.conf на Mac. Старые системы DSM 7.1 и DSM 6.2 не имеют этого переключателя и требуют клиентского обходного решения. Synology подтвердила в публикациях сообщества, что DSM 7.2.3 сделает обязательную подпись настройкой по умолчанию для новых установок.

QNAP QTS. QTS 5.1.7 добавил аналогичный параметр в «Панели управления» → «Сетевые службы и файловые службы» → Win/Mac/NFS/WebDAV → «Дополнительные параметры SMB». Переключатель называется «Принудительная SMB-подпись». Включение работает у большинства пользователей, хотя часть из них сообщила, что стек SMB в QTS корректно согласовывает параметры только после пересоздания самого ресурса. Бета-версия QTS 5.2.0 находится на тестировании и, по ожиданиям, сделает обязательную подпись настройкой по умолчанию.

UGREEN UGOS. UGREEN реагировал медленнее. По состоянию на конец апреля 2026 года UGOS 1.4 добавил бета-прошивку, включающую SMB 3.1.1 с обязательной подписью, однако прошивка ещё не вышла в статусе GA и доступна через бета-канал. Владельцам устройств UGREEN со стабильной прошивкой UGOS следует рассчитывать на обходное решение nsmb.conf в ближайшие несколько недель.

TrueNAS. TrueNAS SCALE 24.10 поставляется с Samba 4.20, которая поддерживает обязательную подпись из коробки. Параметр включается редактированием вспомогательных параметров службы SMB с добавлением server signing = mandatory. После внесения изменения необходимо перезапустить службу SMB. Пользователям TrueNAS CORE со старыми версиями Samba может потребоваться обновление, прежде чем серверное исправление станет доступным.

Asustor ADM. ADM 4.3.1 добавил переключатель «Принудительная SMB-подпись» в разделе «Службы» → Win/Mac/NFS, однако включение на старых устройствах Asustor с бюджетными процессорами, по имеющимся данным, снижает пропускную способность SMB на 20–30 процентов из-за накладных расходов на пакетную подпись. Этот компромисс может склонить пользователей Asustor к клиентскому обходному решению на Mac.

Другие производители. Drobo, WD My Cloud Pro и ряд небольших производителей ещё не выпустили обновления прошивок. Обходное решение nsmb.conf применимо во всех случаях. Если ваш NAS работает на современной версии Samba (4.18 или новее), включение server signing = mandatory в smb.conf устройства также должно сработать, однако это стоит пробовать только при готовности самостоятельно поддерживать конфигурацию Samba.

Для тех, кто задумывается о долгосрочной стратегии резервного копирования без зависимости от единой уязвимой точки, в руководстве лучшая стратегия резервного копирования Mac в 2026 году объясняется, как сочетать Time Machine с iCloud и локальным клоном для достижения надёжности.

Компромиссы безопасности при ослаблении SMB-подписи

Отключение signing_required в nsmb.conf — это реальное изменение вашей позиции в области безопасности, а не косметический переключатель. Стоит честно оценить, что именно вы меняете.

Когда SMB-подпись обязательна, злоумышленник, занявший позицию «человек посередине» в вашей локальной сети, не может подделать SMB-трафик при передаче. Без подписи достаточно мотивированный злоумышленник в той же сети Layer 2 может перехватывать SMB-пакеты и изменять содержимое файлов при их записи на NAS. Для этого злоумышленник должен находиться в вашей проводной локальной сети, сети Wi-Fi или VPN, работающем в том же широковещательном домене. Ему также потребуется техническая квалификация для запуска инструмента SMB MITM — это нетривиально, но и не экзотично.

Для типичной домашней среды с одной сетью Wi-Fi под вашим управлением, доверенным маршрутизатором и отсутствием ненадёжных устройств в локальной сети практический риск атаки SMB MITM очень низок. Наиболее распространённый злоумышленник в домашней локальной сети — это вредоносное ПО на другом вашем устройстве, и этот сценарий в значительной мере выходит за рамки SMB-подписи: вредоносное ПО имело бы собственные учётные данные и не нуждалось бы в атаке MITM на ваш Mac.

В офисной среде, коворкинг-пространстве или любом месте, где в сеть регулярно подключаются ненадёжные устройства, расчёт иной. Коллега, подключивший Raspberry Pi, гостевое устройство с вредоносным ПО или скомпрометированная IoT-камера — всё это может создать угрозу для неподписанного SMB-трафика. В таких средах правильный ответ — не ослаблять подпись на Mac, а обновить прошивку NAS, чтобы подпись оставалась обязательной на протяжении всей цепочки.

Разумным компромиссом является использование в nsmb.conf серверного раздела для ослабления подписи только для имени хоста NAS, на которое нацелен Time Machine, оставив глобальную настройку signing_required=yes. Так все остальные SMB-соединения останутся защищёнными, а ослабление распространяется только на тот хост, которому вы готовы доверять в своей локальной сети.

Также стоит отметить, что весь SMB-трафик в macOS не шифруется по умолчанию, если только сервер явно не включает шифрование SMB (отдельная функция, отличная от подписи). Если вас беспокоит конфиденциальность содержимого резервных копий в сети, включение шифрования SMB на стороне NAS более эффективно, чем подпись, и не взаимодействует с регрессией 26.4.

Альтернативы на время ожидания

Если редактирование системных конфигурационных файлов — не ваше представление об отдыхе в выходные, или если вас не устраивает компромисс по безопасности, существует несколько альтернативных стратегий резервного копирования, которые можно запускать параллельно или вместо Time Machine на NAS. Использование двух из них даёт резервирование до решения проблемы.

Внешний SSD через Time Machine. SSD с прямым подключением по USB-C стоит примерно столько же, сколько один отсек NAS, и обеспечивает нативное подписанное резервное копирование Time Machine без уровня SMB. Samsung T7 или Crucial X9 Pro ёмкостью 2 ТБ вместит месяцы инкрементных резервных копий для большинства пользователей. Подключайте его каждый вечер, дожидайтесь завершения резервного копирования, затем отключайте и храните за пределами дома для защиты от программ-вымогателей. Недостаток — ручное обращение, от которого большинство людей отказываются в течение двух недель.

Carbon Copy Cloner. Carbon Copy Cloner (CCC) от Bombich Software создаёт загрузочные или незагрузочные клоны вашего Mac на любое назначение, включая SMB-ресурсы. CCC самостоятельно устанавливает SMB-сессию, не завися от Time Machine, и включает собственную логику повторных попыток, которая оказалась более устойчивой к регрессии 26.4, чем сам Time Machine. Лицензия единовременная, пробный период щедрый. CCC — самый популярный выбор для пользователей, которым нужен полноценный инструмент резервного копирования на время ожидания исправления Apple.

SuperDuper. SuperDuper от Shirt Pocket Software — ещё один давно зарекомендовавший себя инструмент клонирования для macOS. Он проще CCC с меньшим набором функций, но и дешевле, что делает его вполне достаточным для пользователей, чья единственная цель — «хранить актуальную копию диска в надёжном месте». SuperDuper надёжнее работает с локальными назначениями, чем с SMB-ресурсами, поэтому хорошо сочетается с подходом на основе внешнего SSD.

Arq Backup в облачное хранилище. Arq — версионированный инструмент резервного копирования, ориентированный на облачные назначения: Backblaze B2, Wasabi, AWS S3 и собственный SFTP-сервер. Разработан для удалённого резервного копирования, шифрует данные на стороне клиента до загрузки и не зависит от стека SMB macOS. Arq — сильное дополнение к локальному резервному копированию, а не полноценная замена: восстановление больших объёмов данных из облака занимает много времени.

Второй Mac в качестве назначения Time Machine. Если у вас есть старый Mac, можно включить на нём общий доступ к файлам и направить Time Machine на основном Mac в папку на вторичном. SMB-соединения macOS — macOS в версии 26.4 работают без проблем, поскольку обе стороны используют один диалект. Это нишевый вариант, но бесплатный при наличии подходящего оборудования.

Комбинация, на которой обычно останавливается большинство пользователей на время ожидания исправления, — задание Carbon Copy Cloner для NAS плюс еженедельная смена внешнего SSD. CCC выполняет ежедневную инкрементную работу и надёжен в версии 26.4, а внешний SSD обеспечивает изолированный запасной вариант, защищающий от всего: от отказа диска NAS до программ-вымогателей, шифрующих сетевой ресурс.

Когда именно macOS 26.5 это исправит?

Apple распространила macOS 26.5 бета 4 среди разработчиков 27 апреля 2026 года под номером сборки 25F5068a. Примечания к бета-версии по-прежнему находятся под соглашением о неразглашении, однако бета-тестеры сообщают, что настройка SMB-подписи по умолчанию была скорректирована так, чтобы подключения Time Machine к типовым конфигурациям NAS успешно устанавливались без ручного вмешательства.

Точный механизм исправления публично не задокументирован. Судя по изменениям, наблюдаемым в журналах согласования SMB, Apple, по всей видимости, восстановила запасной путь для SMB-сессий, в которых сервер объявляет подпись поддерживаемой, но не обязательной, при этом запасной вариант ограничен доступом к sparsebundle Time Machine. Это должно сохранить улучшения безопасности для общего использования SMB, одновременно восстановив функциональность резервного копирования для затронутой аудитории NAS.

Публичный график выхода 26.5 не подтверждён, однако следует предсказуемой закономерности. Apple обычно нацелена на конец мая для финального точечного релиза перед WWDC основной версии macOS, а WWDC 2026 запланирована на понедельник 8 июня. Бета 4 в конце апреля, затем бета 5 в начале мая и кандидат на выпуск в середине мая дадут публичный релиз в окне с 19 по 26 мая, плюс-минус несколько дней.

Подробный обзор остальных нововведений цикла 26.5 — новых функций Apple Intelligence, переработанных Напоминаний и долгожданной переработки Mail — можно найти в нашем полном руководстве по macOS Tahoe 26.5 бета 1.

Когда 26.5 выйдет и вы убедитесь в работоспособности Time Machine без обходного решения, не забудьте удалить или вернуть /etc/nsmb.conf в исходное состояние, чтобы восстановить настройки SMB-подписи по умолчанию для всех сетевых подключений.

Контрольный список устранения неполадок

Если обходное решение nsmb.conf не исправляет Time Machine с первого раза, проработайте этот контрольный список перед тем, как предполагать более экзотическую причину проблемы.

Отмонтируйте и снова смонтируйте ресурс. macOS кэширует согласованную SMB-сессию для ресурса, пока тот полностью не отмонтирован. Через Finder отмонтируйте ресурс NAS, подождите десять секунд, затем снова подключитесь через Finder, введя путь к ресурсу вручную. Только после этого запускайте резервное копирование Time Machine.

Перезапустите Mac. Ряд пользователей сообщает, что SMB-клиент не подхватывает новый nsmb.conf до следующей перезагрузки. Перезапуск быстрее, чем дальнейшая диагностика.

Обновите прошивку NAS. Даже если ваш NAS ещё не имеет исправления для Tahoe, последнее обновление прошивки могло улучшить согласование SMB таким образом, что оно лучше взаимодействует с изменениями macOS. Synology DSM 7.2.2u4, QNAP QTS 5.1.7 и TrueNAS SCALE 24.10 — минимально рекомендуемые версии.

Проверьте права доступа к ресурсу. Убедитесь, что учётная запись пользователя, от имени которой Time Machine подключается к NAS, имеет права на чтение и запись в ресурс Time Machine. Некоторые обновления прошивки NAS сбрасывают разрешения в процессе обновления.

Проверьте целостность sparsebundle. Если предыдущая попытка резервного копирования оставила неполный sparsebundle, смонтируйте его вручную и запустите hdiutil verify. Повреждённые sparsebundle вызовут сбой Time Machine даже после исправления уровня SMB. В серьёзных случаях удаление sparsebundle и начало заново — наиболее чистый путь.

Убедитесь, что назначение Time Machine распознаётся. Откройте «Системные настройки» → «Основные» → Time Machine и проверьте, по-прежнему ли назначение отображается в списке. Если оно исчезло, добавьте его заново после нормализации уровня SMB.

Проверьте сетевую связность. Убедитесь, что Mac вообще достигает NAS, сделав ping из Terminal. SMB требует как IP-соединения, так и доступности портов SMB (обычно 445).

Изучите журнал ядра. После неудачного резервного копирования выполните log show --last 5m --predicate 'process == "kernel"' | grep smb. Ошибки SMB на уровне ядра покажут, на каком этапе происходит сбой: согласование подписи, аутентификация, подключение к дереву или уровень файловых операций.

Если после всего этого резервное копирование по-прежнему не работает, ваша конкретная комбинация прошивки NAS может быть нестандартным случаем, требующим подхода serverMarkers.plist или изменения smb.conf на стороне NAS. Публикация модели NAS, версии прошивки и точных строк журнала ядра на соответствующем форуме производителя — как правило, самый быстрый способ получить рабочее исправление.

Часто задаваемые вопросы

В: Влияет ли обходное решение nsmb.conf на SMB-соединения с моим компьютером Windows? О: Да. Любое изменение в разделе [default] распространяется на все SMB-соединения вашего Mac. Чтобы оставить соединения с Windows строгими, ограничьте изменение серверным разделом, используя имя хоста NAS в качестве имени раздела.

В: Нужно ли будет повторять полное резервное копирование Time Machine после применения исправления? О: Нет. После корректного установления SMB-сессии Time Machine продолжит с того места, где остановился, и запишет следующую инкрементную копию. Полное повторное резервное копирование требуется только в случае, если сам sparsebundle был повреждён предыдущей неудачной попыткой.

В: Я попробовал исправление, но Time Machine по-прежнему не работает. Что теперь? О: Пройдитесь по контрольному списку устранения неполадок выше, уделив особое внимание строкам журнала ядра. Наиболее распространённая последующая причина — повреждённый sparsebundle от предыдущей неудачной попытки, а не оставшаяся проблема SMB.

В: Безопасно ли применять исправление на Mac, который я беру в коворкинг? О: Это безопаснее, чем запускать неподписанный SMB к домашнему NAS из сети коворкинга, однако наиболее чистый ответ — обновить прошивку NAS, чтобы серверная подпись стала обязательной, или ограничить исключение в nsmb.conf только именем хоста домашнего NAS.

В: Нужно ли повторять исправление после каждого обновления macOS? О: Файл /etc/nsmb.conf сохраняется между обновлениями. Повторное применение должно потребоваться только если обновление явно сбрасывает системные конфигурационные файлы, что бывает крайне редко.

В: Сломает ли исправление резервное копирование iCloud, AirDrop или другие сервисы Apple? О: Нет. Эти сервисы не используют SMB и не затронуты изменениями в nsmb.conf.

В: Можно ли применить то же исправление на macOS Sequoia или Sonoma? О: Формат файла идентичен, те же строки работают, однако на Sequoia или Sonoma это не нужно: изменение SMB-подписи характерно только для Tahoe 26.4. Применять исправление на старых версиях macOS безвредно, но излишне.

В: Производитель моего NAS говорит, что у него есть обновление прошивки, исправляющее проблему. Нужно ли оставлять nsmb.conf? О: После применения обновления прошивки и подтверждения работы Time Machine без обходного решения удалите nsmb.conf. Сохранять ослабление не нужно — это лишь снизит ваш базовый уровень безопасности.

В: Есть ли GUI-инструмент для редактирования nsmb.conf? О: Официального инструмента от Apple нет. На GitHub есть несколько инструментов от сторонних разработчиков, однако для двухстрочного файла подход через Terminal быстрее и несёт меньше рисков, чем установка новой утилиты.

В: Когда выйдет версия 26.5, Apple портирует исправление в 26.4? О: Apple не объявляла о патче 26.4.2, устраняющем регрессию SMB. Исторически Apple предпочитает включать исправления в следующий крупный точечный выпуск, а не выполнять бэкпортирование, особенно для некритичных с точки зрения безопасности регрессий. Планируйте переход на 26.5 как на окончательное решение.

Заключение

Изменение SMB-подписи в macOS Tahoe 26.4 было верным решением с точки зрения безопасности, однако отсутствие координации с производителями поставило NAS-резервное копирование Time Machine в непростое положение на несколько недель. Обходное решение через /etc/nsmb.conf компактно, обратимо и решает непосредственную проблему. Более долгосрочный ответ — поддерживать актуальность прошивки NAS, чтобы подпись была обязательной на стороне сервера, восстанавливая строгое подписание на всём протяжении соединения.

Если вы читаете это в конце мая 2026 года или позже, проверьте, вышел ли macOS 26.5, прежде чем применять обходное решение. Если 26.5 доступен, установите его: резервное копирование Time Machine должно возобновиться без каких-либо изменений системных файлов. Если вы применяли обходное решение и 26.5 уже установлен, потратьте пять минут на откат nsmb.conf и убедитесь, что резервное копирование работает и с восстановленной строгой подписью.

Резервное копирование — это та инфраструктура, о которой вспоминают лишь при поломке, и регрессия 26.4 — полезное напоминание о рисках зависимости от единственного места хранения резервных копий. Какой бы путь исправления вы ни выбрали на этой неделе, подумайте о добавлении второго независимого назначения для резервного копирования до прихода следующего обновления macOS.

Дополнительное чтение

• Полное руководство по устранению неполадок Time Machine для macOS Tahoe
• Устранение неполадок SMB и NAS в macOS Tahoe
• Лучшая стратегия резервного копирования Mac в 2026 году: Time Machine, iCloud и инструменты клонирования
• Полное руководство по обновлению macOS Tahoe 26.4 и 26.4.1
• macOS Tahoe 26.5 бета 1: что нового и что исправлено
• Полное руководство по createinstallmedia: возврат к чистой установке macOS