Ошибка 1219 и разные пароли к общей папке: как разобраться с сохранёнными подключениями

Что означает ошибка 1219

Вы открыли одну папку сервера под обычным пользователем, затем пытаетесь подключить вторую под администратором. Windows сообщает о нескольких подключениях с разными именами пользователя. Это может быть конфликтом уже установленного входа, даже если новый пароль верен.

Ограничение относится к подключениям к одному серверу в соответствующем контексте входа пользователя. Другая буква сетевого диска не создаёт автоматически независимую учётную запись к тому же серверу. Microsoft описывает такое поведение как предусмотренное системой. ^[1]

Сохраните работу и определите нужный сервер

Закройте документы и дождитесь окончания копирования, резервного копирования и синхронизации с этим сервером. Разрыв подключения во время записи может привести к ошибке приложения. Закройте окна Проводника и терминалы, где текущий каталог находится на его ресурсе.

Запишите все формы адреса: \\NAS\Archive, полное имя, IP, прежний псевдоним. Убедитесь, что они действительно относятся к одному устройству. В примерах дальше сервер называется NAS; замените его своим именем. Не отправляйте пароль в чат или в диагностический лог.

Начинайте в той же обычной сессии Windows, где возникает ошибка. Повышенная консоль и Проводник могут видеть разные сопоставления дисков из-за разделения контекстов UAC; пустой список в одной консоли не опровергает подключение в другой. ^[2]

Посмотрите подключения, сопоставления и сохранённые записи

В командной строке:

net use
cmdkey /list

В PowerShell:

Get-SmbMapping |
  Format-Table LocalPath, RemotePath, Status -Auto
Get-SmbConnection | Format-List *

Net use показывает текущие сетевые подключения, Get-SmbMapping — сопоставления, Get-SmbConnection — сведения об установленных SMB-соединениях. Cmdkey перечисляет сохранённые учётные данные: наличие записи не означает, что именно она используется текущим сеансом. Поле Credential или UserName в свойствах соединения помогает сопоставлению. ^{[3], [4], [5], [6]}

Обратите внимание на подключения без буквы и служебный ресурс IPC$, если они показаны. Удаление диска Z: не обязательно устраняет все соединения к NAS. Приложение также может немедленно установить новое соединение после удаления старого.

Отключите только ресурсы этого сервера

После закрытия работающих с NAS программ удалите конкретное сопоставление:

net use Z: /delete

Z: — пример существующей буквы из вашего списка. Для подключения без буквы используют точный путь, например:

net use "\\NAS\Archive" /delete

Повторите для остальных показанных подключений к тому же серверу, включая IPC$, если он есть и вы понимаете, кто его использует. Команда может предупредить об открытых файлах; сначала вернитесь к приложениям и завершите операции. Не подтверждайте принудительный разрыв вслепую. ^[3]

Здесь намеренно не используется net use * /delete: эта команда отменяет все сетевые подключения, в том числе к другим серверам. Она может нарушить несвязанные рабочие процессы и скрыть, какое соединение создавало конфликт.

Снова выполните net use и Get-SmbConnection в исходном контексте. Если NAS остаётся, закройте удерживающую его программу. Когда источник не найден, выход пользователя из Windows после сохранения всей работы бывает понятнее массового удаления настроек. Простая блокировка экрана не завершает вход.

Исправьте сохранённую запись отдельно от сеанса

Откройте Панель управления → Диспетчер учётных данных → Учётные данные Windows. Найдите запись, относящуюся именно к используемому имени NAS, и удалите или исправьте её после проверки назначения. Сохранённые записи для IP и полного имени могут отличаться.

В командной строке Cmdkey позволяет удалить конкретную цель:

cmdkey /delete:NAS

NAS в этой команде — пример целевого имени. Сопоставьте его с полем Target в cmdkey /list; если цель у вас названа иначе, используйте её фактический идентификатор. Не удаляйте записи других служб из-за похожего названия. Удаление сохранённой записи не закрывает уже работающий SMB-сеанс и не меняет пароль на NAS. ^[6]

Подключитесь заново без пароля в истории команд

Выберите свободную букву и учётную запись самого NAS:

net use Z: "\\NAS\Archive" * /user:NAS\archiveuser /persistent:no

Звёздочка вызывает отдельный запрос пароля; пароль не нужно вписывать в команду. NAS\archiveuser — учебный формат локальной записи устройства; для доменной записи используют домен, для отдельных NAS — формат из руководства производителя. Параметр persistent:no не делает создаваемое сопоставление постоянным. ^[3]

Проверьте чтение нужного файла и, если разрешено, запись одного тестового файла. Затем Get-SmbConnection должен показывать ожидаемый сервер и пользователя. Если теперь возникает «Отказано в доступе», выясняют права папки и NAS; это уже другой этап, а не прежний конфликт 1219.

Почему подключение по IP или псевдониму не всегда хорошее исправление

В старом руководстве Microsoft IP-адрес и другой DNS-псевдоним описаны как обход: клиент может считать их другим сервером. Но современная рекомендация по подписи SMB советует пользоваться корректной идентификацией сервера и Kerberos, избегать IP и произвольных CNAME. ^{[1], [7]}

Поэтому сначала приводят к одному ожидаемому входу обычное имя NAS. В домене дополнительные имена и SPN настраивает администратор. Бесконтрольное чередование IP, короткого имени и псевдонимов усложняет учёт паролей и проверку подлинности.

Если одновременно нужны разные роли, лучше разделить рабочие процессы по отдельным входам пользователей или согласованной архитектуре доступа. Разные папки одного сервера сами по себе не дают каждому подключению независимый набор логинов.

Если конфликт возвращается после входа в Windows

Проверьте восстанавливаемые сетевые диски, сценарии входа и приложения резервного копирования. Повторите снимок net use сразу после входа и после запуска подозреваемой программы. Для службы важна её собственная учётная запись; исправление пароля в Проводнике не обязательно меняет настройки службы.

Сохраните время появления первого соединения, его имя сервера, ресурс, пользователя и контекст. Этот набор обычно полезнее повторного удаления всех учётных данных. После исправления проверьте, что доступ сохранился именно в обычной сессии, из которой пользователь работает с файлами.