System error 1219 has occurred

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

С тех пор не перфолент было испорчено, а программно-аппаратные комплексы, компьютеры с которыми мы работаем, стали на несколько десятков порядков более сложными. И ошибки в них возникают порой настолько экзотические, что решить их зачастую практически невозможно, так как легче переустановить заново Windows и сбросить Linux.

Именно о такой «ошибке» и пойдет дальше речь. Действие происходит в среде операционной системы Windows 10. Разрядность или редакция системы не имеет значения. При попытке подключения к сервису Samba удаленного сервера в локальной сети на Linux при использовании команды net use возникает ошибка множественного доступа:

System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Ошибка будет возникать и при попытке подключиться к «расшареной папке» на удаленном сервере обычным проводником. Гугленье по номеру и описанию ошибки ни к каким позитивным результатам не приводит, так как ошибка настолько старая, что даже ссылки на базу знаний Microsoft ведут на страницу ошибки об отсутствии ошибки, а не на описание того, как с появившейся бедой справиться.

В моем случае я пытался подключать сетевой диск из командного файла. Операция проводилась командой:

NET USE B: \192.168.1.11BU BU2 /user:BUS /persistent:no

Где в качестве диска B: примонтировывалась папка BU с сервера, заданного IP-адресом 192.168.1.11. При этом подключение осуществлялось под пользователем BUS с паролем BU2. И подключение существовало до перезагрузки (или его можно было отключить командой NET USE B: /DELETE).

Но, начнем по порядку. Давным-давно, по причинам ведомым одним только разработчикам, да архитекторам Microsoft, сетевые подключения к сервисам удаленный папки (та самая Samba) жестко ограничивались только одним пользователем на один сервер. Что это значит? Это значит, что на один сервер можно подключиться только под одной парой Login/Password. И если вы уже открыли один такой сеанс и не отключились от него (а Windows обычно не отключает соединение, чтобы потом не тратить время на его подключение заново), то при второй попытке подключиться к этому же серверу возникает как раз ошибка 1219. Собственно, описание проблемы и способ ее решения приводится непосредственно при выводе кода 1219. Дескать надо убрать другие подключения, тогда все заработает.

Многие «решения» и советы в сети сводятся примерно к следующему:

1. Перезагрузиться. Самый универсальный совет. И таки да, все заработает, если, конечно, у вас нет какого-либо автоматического подключения к удаленному серверу по Samba в автозагрузке. (По этому поводу встречался и совсем экзотический вариант по перезагрузке сервиса Workstation, дескать быстрее, да и все остальное не закроется, но это уже какой-то Overkill).

2. Удалить существующие подключения без перезагрузки. Вариант немного сложнее, но работает не хуже. Для этого придется поработать руками. Заходим в командную строку Windows (мой любимый способ через Win-X и там уже выбрать). Вводим команду NET USE. Она возвращает нам список подключенных удаленных папок. Затем удаляем ненужное подключение через NET USE xxx /DELETE, где xxx тот ресурс в качестве которого у нас подключена удаленная папка. Либо же удаляем вообще все подключения через NET USE * /DELETE.

3. Далеко не у всех пункты 1 и 2 срабатывают. Поэтому самые hard-core users советуют заодно «почистить» всё остальное, что так или иначе касается сетевых подключений. Все делается там же, в командной строке, после проведения операции из пункта 2. Поочередно запускаем следующие команды:

ipconfig /release
ipconfig /flushdns
ipconfig /renew

Все вышеприведённые варианты должны, просто обязаны, помочь в проблеме. Но, что, если нет? Например, если NET USE возвращает, что у вас в системе нет никаких подключений? Мой NET USE просто отписывался «There are no entries in the list.», так как банально не видел подключений сделанных и сохраненных через проводника.

В таком случае поступаем другим, не менее интересным способом. Но для его понимания, нужно понять каким образом сетевой стек в Windows идентифицирует удаленные сервера. А делает он это очень просто. По какому сетевому имени к серверу подключаешься, так он его и запоминает. В моем варианте я подключался через проводник и в командном файле к серверу по его IP-адресу (192.168.1.11). Но ведь у сервера есть еще и его сетевое имя. У меня он зовется N3050. И вместо NET USE B: \192.168.1.11BU BU2 /user:BUS /persistent:no я могу вполне резонно воспользоваться NET USE B: \N3050BU BU2 /user:BUS /persistent:no и все заработает.

А если подключений к одному серверу с разными учетными данными требуется еще больше, то можно воспользоваться другой техникой: прописать в сетевые или локальные таблицы связей IP-адресов и имен дополнительные псевдонимы. В среде Windows проще всего изменить файл hosts, который обыкновенно гнездится по следующему пути WindowsSystem32driversetc.

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

---

---

Многобукфф

Vladislav’s personal blog site

System error 1219 has occurred.

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

С тех пор не перфолент было испорчено, а программно-аппаратные комплексы, компьютеры с которыми мы работаем, стали на несколько десятков порядков более сложными. И ошибки в них возникают порой настолько экзотические, что решить их зачастую практически невозможно, так как легче переустановить заново Windows и сбросить Linux.

Именно о такой «ошибке» и пойдет дальше речь. Действие происходит в среде операционной системы Windows 10. Разрядность или редакция системы не имеет значения. При попытке подключения к сервису Samba удаленн ого сервера в локальной сети на Linux при использовании команды net use возникает ошибка множественного доступа:

System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

Ошибка будет возникать и при попытке подключиться к «расшареной папке» на удаленном сервере обычным проводником. Гугленье по номеру и описанию ошибки ни к каким позитивным результатам не приводит, так как ошибка настолько старая, что даже ссылки на базу знаний Microsoft ведут на страницу ошибки об отсутствии ошибки, а не на описание того, как с появившейся бедой справиться.

В моем случае я пытался подключать сетевой диск из командного файла. Операция проводилась командой:

NET USE B: \192.168.1.11BU BU2 /user:BUS /persistent:no

Где в качестве диска B: примонтировывалась папка BU с сервера, заданного IP-адресом 192.168.1.11. При этом подключение осуществлялось под пользователем BUS с паролем BU2. И подключение существовало до перезагрузки (или его можно было отключить командой NET USE B: /DELETE).

Но, начнем по порядку. Давным-давно, по причинам ведомым одним только разработчикам, да архитекторам Microsoft, сетевые подключения к сервисам удаленный папки (та самая Samba) жестко ограничивались только одним пользователем на один сервер. Что это значит? Это значит, что на один сервер можно подключиться только под одной парой Login/Password. И если вы уже открыли один такой сеанс и не отключились от него (а Windows обычно не отключает соединение, чтобы потом не тратить время на его подключение заново), то при второй попытке подключиться к этому же серверу возникает как раз ошибка 1219. Собственно, описание проблемы и способ ее решения приводится непосредственно при выводе кода 1219. Дескать надо убрать другие подключения, тогда все заработает.

Многие «решения» и советы в сети сводятся примерно к следующему:

1. Перезагрузиться. Самый универсальный совет. И таки да, все заработает, если, конечно, у вас нет какого-либо автоматического подключения к удаленному серверу по Samba в автозагрузке. (По этому поводу встречался и совсем экзотический вариант по перезагрузке сервиса Workstation, дескать быстрее, да и все остальное не закроется, но это уже какой-то Overkill).

2. Удалить существующие подключения без перезагрузки. Вариант немного сложнее, но работает не хуже. Для этого придется поработать руками. Заходим в командную строку Windows (мой любимый способ через Win-X и там уже выбрать). Вводим команду NET USE. Она возвращает нам список подключенных удаленных папок. Затем удаляем ненужное подключение через NET USE xxx /DELETE, где xxx тот ресурс в качестве которого у нас подключена удаленная папка. Либо же удаляем вообще все подключения через NET USE * /DELETE.

3. Далеко не у всех пункты 1 и 2 срабатывают. Поэтому самые hard-core users советуют заодно «почистить» всё остальное, что так или иначе касается сетевых подключений. Все делается там же, в командной строке, после проведения операции из пункта 2. Поочередно запускаем следующие команды:

ipconfig /release
ipconfig /flushdns
ipconfig /renew

Все вышеприведённые варианты должны, просто обязаны, помочь в проблеме. Но, что, если нет? Например, если NET USE возвращает, что у вас в системе нет никаких подключений? Мой NET USE просто отписывался «There are no entries in the list.», так как банально не видел подключений сделанных и сохраненных через проводника.

В таком случае поступаем другим, не менее интересным способом. Но для его понимания, нужно понять каким образом сетевой стек в Windows идентифицирует удаленные сервера. А делает он это очень просто. По какому сетевому имени к серверу подключаешься, так он его и запоминает. В моем варианте я подключался через проводник и в командном файле к серверу по его IP-адресу (192.168.1.11). Но ведь у сервера есть еще и его сетевое имя. У меня он зовется N3050. И вместо NET USE B: \192.168.1.11BU BU2 /user:BUS /persistent:no я могу вполне резонно воспользоваться NET USE B: \N3050BU BU2 /user:BUS /persistent:no и все заработает.

А если подключений к одному серверу с разными учетными данными требуется еще больше, то можно воспользоваться другой техникой: прописать в сетевые или локальные таблицы связей IP-адресов и имен дополнительные псевдонимы. В среде Windows проще всего изменить файл hosts, который обыкновенно гнездится по следующему пути WindowsSystem32driversetc.

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

Опубликовано 25.11.2018 автором kvv213 в следующих категориях:
Soft статья

Источник

System error 1219 had occurred

This forum is closed. Thank you for your contributions.

Answered by:

Question

I am running Windows Vista Home Premium SP1 on my laptop. I have a Fedora Core 7 server running SaMBa. They share a /28 subnet (with 0, 6, and 7 taken by networking, 1 — 4 on the server, 5 on the laptop).

The server has multiple SaMBa shares (for this example, \myservershare1 and \myservershare2). There are two SaMBA users, user1 and user2, each either their own passwords. user1 can access \myservershare1 and user2 can access \myservershare2 . I log on to the Vista laptop using a separate user/pass from either of those two accounts.

When I attempt to connect to these shares, I can do so without a problem if I connect to them singly using «connect using different user name». However, if I attempt to connect to both simultaneously, I get:

«System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.»

I need to be able to connect to both shares simultaneously, but using the different credentials (I don’t want user1 creating files in \myservershare2 and I don’t want user2 creating files in \myservershare1).

I have tried manually using NET USE and I get the same error when I try to map the second drive after the first is mounted. I have also messed with regedit and changed HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaLmCompatibilityLevel from 3 to 1 (a certain site suggested this). I’ve also seen some DNS kludges that trick the windows client into thinking its connecting to multiple servers but I haven’t the capacity to arrange something like this easily — nor do I like the idea of using kludges to fix what should be a simple-to-fix scenario.

Is there a ‘correct’ work-around for this?

Answers

• Proposed as answer by Shem Sargent Monday, April 2, 2012 3:10 PM
• Marked as answer by Carey Frisch MVP, Moderator Saturday, June 16, 2018 4:56 PM

Please understand that this behavior is by design for security purpose, Windows only allow per user per SMB connect at a machine. To make the connection with the other account, please disconnect the previous connection(s) to the server. You may use the command net use /delete.

In what way does this really provide any sort of security benefit? If I can get around this simply by having multiple HOSTS or DNS entries for the one server, then there’s really not a one-user/one-SMB limitation, just a minor annoyance.

For example, if I tether ‘samba1 192.168.138.1’ and ‘samba2 192.168.138.1’ in my HOSTS file on windows, then connect Y: to \samba1myshare1 and Z: to \samba2myshare2, the system will gladly connect me to both even using two different user names and two different passwords, forming a rather simple and straight-forward workaround.

So ultimately, the limitation doesn’t exist — only an annoyance exists, and one so easily circumvented that from my point of view, it’s no security at all.

Could you provide more detail on exactly how this limitation is a security feature? What risk does it mitigate? Why is that risk considered critical enough to create such a severe functional limitation? I certainly don’t see a positive cost-benefit analysis in this detail, but I would be interested in knowing Microsoft’s cost-benefit analysis on it.

I have unmarked the previous post as being an Answer because while it raises the security issue, it does not explain in what way this is a security feature and further does not answer the question asked. However, understanding that information, I will accept an explanation of why the limitation exists in the first place as an answer.

Источник

System error 1219 had occurred

This forum is closed. Thank you for your contributions.

Answered by:

Question

I am running Windows Vista Home Premium SP1 on my laptop. I have a Fedora Core 7 server running SaMBa. They share a /28 subnet (with 0, 6, and 7 taken by networking, 1 — 4 on the server, 5 on the laptop).

The server has multiple SaMBa shares (for this example, \myservershare1 and \myservershare2). There are two SaMBA users, user1 and user2, each either their own passwords. user1 can access \myservershare1 and user2 can access \myservershare2 . I log on to the Vista laptop using a separate user/pass from either of those two accounts.

When I attempt to connect to these shares, I can do so without a problem if I connect to them singly using «connect using different user name». However, if I attempt to connect to both simultaneously, I get:

«System error 1219 has occurred.

Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.»

I need to be able to connect to both shares simultaneously, but using the different credentials (I don’t want user1 creating files in \myservershare2 and I don’t want user2 creating files in \myservershare1).

I have tried manually using NET USE and I get the same error when I try to map the second drive after the first is mounted. I have also messed with regedit and changed HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsaLmCompatibilityLevel from 3 to 1 (a certain site suggested this). I’ve also seen some DNS kludges that trick the windows client into thinking its connecting to multiple servers but I haven’t the capacity to arrange something like this easily — nor do I like the idea of using kludges to fix what should be a simple-to-fix scenario.

Is there a ‘correct’ work-around for this?

Answers

• Proposed as answer by Shem Sargent Monday, April 2, 2012 3:10 PM
• Marked as answer by Carey Frisch MVP, Moderator Saturday, June 16, 2018 4:56 PM

Please understand that this behavior is by design for security purpose, Windows only allow per user per SMB connect at a machine. To make the connection with the other account, please disconnect the previous connection(s) to the server. You may use the command net use /delete.

In what way does this really provide any sort of security benefit? If I can get around this simply by having multiple HOSTS or DNS entries for the one server, then there’s really not a one-user/one-SMB limitation, just a minor annoyance.

For example, if I tether ‘samba1 192.168.138.1’ and ‘samba2 192.168.138.1’ in my HOSTS file on windows, then connect Y: to \samba1myshare1 and Z: to \samba2myshare2, the system will gladly connect me to both even using two different user names and two different passwords, forming a rather simple and straight-forward workaround.

So ultimately, the limitation doesn’t exist — only an annoyance exists, and one so easily circumvented that from my point of view, it’s no security at all.

Could you provide more detail on exactly how this limitation is a security feature? What risk does it mitigate? Why is that risk considered critical enough to create such a severe functional limitation? I certainly don’t see a positive cost-benefit analysis in this detail, but I would be interested in knowing Microsoft’s cost-benefit analysis on it.

I have unmarked the previous post as being an Answer because while it raises the security issue, it does not explain in what way this is a security feature and further does not answer the question asked. However, understanding that information, I will accept an explanation of why the limitation exists in the first place as an answer.

Источник