Проблема с доступом к папке в сети без домена
 

Всем привет!

Что то я голову уже сломал с этой проблемой...

Одноранговая сеть из нескольких компьютеров, на всех W10x64
Задача дать доступ на ПК1 к папке определенным пользователям в сети.

Создал на ПК1 пользователя "1", права админа и дал ему пароль, идентичный пользователь с таким же паролем существует на ПК2, ПК3, ПК4.
Создал на ПК1 каталог к которому необходим доступ с ПК2, ПК3, ПК4, дал полные права пользователю "1", "Администраторы", "Администратор", "Прошедшие проверку" и оно не работает! что не хватает?!

Авторизация должна быть без ввода пароля т.к. пользователи одинаковые на всех ПК, получаю сообщение:
Windows не может получить доступ к ...

dddimmm, попробуйте через "Подключить сетевой диск", указав нужного юзера и полный путь до нужной папки

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

пробовали и не подключается или не хотите пробовать?

Есть кое какие подвижки!

Включил на всех машинах компоненту "Поддержка общего доступа к файлам SMB 1.0/CIFS" и разрешил "Включить небезопасные гостевые входы" в gpedit.msc, Конфигурация компьютера-Административные шаблоны-Сеть-Рабочая станция Lanman

В расшаренный каталог стало пускать, но не дает возможности что либо создавать внутри расшаренного каталога, доступ при этом для пользователя ПОЛНЫЙ. Такое впечатление что пользователь как то криво проверяется. Пробовал так же отключать брандмауэр

"Вам необходимо разрешение на выполнение этой операции"

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

Включил для проверки "Включить общий доступ с парольной защитой" чтобы вручную вбить логин и пароль...и что вы думаете...ввожу в появившееся окно авторизации логин и пароль и авторизация не проходит! Сервер не распознает данного пользователя! Как так?! Пользователь один и тот же с одинаковым паролем, проверил раз 10. Что за глюк?

в копилке глюков пополнение

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

Винда лицензионная, обновления все актуальные

dddimmm
Доступ к общей папке настраивается в два этапа. Сначала проверяется сетевой доступ к каталогу, затем проверяются локальные права пользователя. По сети проще всего дать доступ всем (скриншот №1), а разграничение прав сделать на уровне самих пользователей (скриншот №2). И еще несколько замечаний...

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

Во-вторых, на клиентских машинах полезно использовать команду Net Use для определения наличия или отсутствия соединений. Прежде чем начинать какие-либо эксперименты, удостоверьтесь, что данная команда не выводит никаких соединений, в ответе должно значиться "В списке нет элементов". Если ответ будет каким-либо другим, то выполните Net Use /Delete * для удаления всех соединений, после чего закройте все открытые папки и подождите 5-10 секунд, чтобы сбросился системный кэш. В свою очередь, на компьютере с общей папкой можно использовать команду OpenFiles для просмотра установленных соединений (однако она ничего не покажет, если пользователь просто открыл компьютер в сетевом окружении, но дальше никуда не пошел, т.е. не стал заходить непосредственно в расшаренные папки).

В-третьих, удостоверьтесь, что на клиентах не сохранено каких-то старых учетных данных (скриншот №3), в противном случае система всегда будет пытаться использовать именно их при входе на указанный компьютер. Для компьютера с общей папкой, кстати, есть нюанс: если вы там добавляете или удаляете пользователей, назначаете им пароли и прочее, то все изменения вступят в силу только после завершения сеанса работы текущего пользователя, несмотря на то, что Windows об этом не предупреждает.

Avatar-Lion,
спасибо что не поленились и написали такой содержательный пост, все это я делал и проверял. Компьютер с общей папкой не принимает учетную запись под которой в эту самую папку пытаются зайти.

dddimmm, нет, вы уж определитесь, пожалуйста, на каком именно этапе возникает проблема. Если вы дважды кликаете на значке компьютера в сетевом окружении и он запрашивает у вас имя пользователя и пароль - это этап аутентификации. Никакого отношения к общим ресурсам этот этап еще не имеет, его можно сравнить с экраном приветствия Windows. Если же вы успешно зашли на компьютер и дважды кликаете на расшаренной папке, а он вас в эту папку не пускает, то это уже следствие некорректно выставленных разрешений для сетевого или локального доступа (скриншоты 1 и 2).

P.S. На всякий случай приложил скриншот с параметрами общего доступа из центра управления сетями на виртуальной машине, на которой я всё это тестировал.

Avatar-Lion,
На данный момент ситуация следующая...

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

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

dddimmm, по запросу "windows не принимает пароль по сети" довольно много чего выдается в поисковиках, можете сами вбить эту фразу и попробовать разные варианты. От себя лично могу пока порекомендовать следующий вариант:
1) На компьютере с общей папкой для пользователя "Dima" установите пароль длиной не менее 15 символов (можно больше).
2) Завершите сеанс и снова зайдите в систему (ну или просто перезагрузите компьютер).
3) Отпишитесь о результатах (ушла проблема или нет).

Avatar-Lion, пароль изменил, ситуация та же, не пускает

а домен-то вписываете? Типа, "COMP1/vasya" или "vasya@COMP1"? Локальный домен должен быть, т.е. тот комп, на который заходите. (в обычных случаях не требуется, но тут, как видно, случай необычный) :biggrin:

dddimmm, на любом клиенте выполните в командной строке от Администратора: CmdKey /List - и покажите результат вывода этой команды.

dmitryst, не помогает

Avatar-Lion,
Сервер:

Microsoft Windows [Version 10.0.19045.2364]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

C:\Users\Dima>CmdKey /List

Текущие сохраненные учетные данные:

Конечный файл: WindowsLive:target=virtualapp/didlogical
Тип: Универсальный
Пользователь: 02amrapjgeejxzng
Постоянное хранение на локальном компьютере


C:\Users\Dima>

Компьютер в сети:

Microsoft Windows [Version 10.0.19045.2364]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

C:\Users\Dima>CmdKey /List

Текущие сохраненные учетные данные:

Конечный файл: WindowsLive:target=virtualapp/didlogical
Тип: Универсальный
Пользователь: 02yshrjdfxbhnyxq
Постоянное хранение на локальном компьютере


C:\Users\Dima>

dddimmm, на клиенте добавьте вручную учетные данные, как я на третьем скриншоте показывал и проверьте зайдет он так на сервер или нет. Если нет, то проверьте что выдаст CmdKey /List.

Avatar-Lion,

на сервер не пускает (

Microsoft Windows [Version 10.0.19045.2364]
(c) Корпорация Майкрософт (Microsoft Corporation). Все права защищены.

C:\Users\Dima>CmdKey /List

Текущие сохраненные учетные данные:

Конечный файл: WindowsLive:target=virtualapp/didlogical
Тип: Универсальный
Пользователь: 02yshrjdfxbhnyxq
Постоянное хранение на локальном компьютере

Конечный файл: Domain:target=PRIEMNAYA
Тип: Пароль домена
Пользователь: Dima


C:\Users\Dima>

dddimmm, понятно. Ну что ж... Если у вас быстрый интернет, то могу разве что предложить снять образ с вашего "сервера" и переслать его мне. Я разверну его на своем рабочем ПК и попробую понять в чем дело. По всем признакам потому что у вас никаких проблем нет, учетные данные на клиенте сохраняются успешно.

интересно, а компы в одной рабочей группе?

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

Avatar-Lion, Я вот что подумал... Может, у ТС где-то используются не-латинские буквы? Я-то еще со времен 2000й это усвоил и везде применяю латиницу, даже если интерфейс системы и локальные настройки русские. Может, в этом затык?

dmitryst, честно говоря, не помню чтобы это когда-то приводило к подобным проблемам. Единственный замеченный минус использования кириллицы в имени учетной записи пользователя - это косяки с некоторыми играми и программами, которые некорректно отрабатывали пути к документам, AppData и прочим папкам.

Avatar-Lion, вам просто повезло )))), но я бы для теста посоветовал использовать что-то типа D:\folder1\123

Наконец-то я доделал кое-что у себя дома и смог провести полноценный эксперимент. Итак, условия:
1) Образ Windows 10 22H2 от декабря (MSDN, Ru)
2) Системный блок на базе Socket 1155 (Windows 10 Pro x64)
3) Ноутбук на AMD-платформе (Windows 10 Home x64)
4) Роутер D-Link DIR-320

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

1) При подключении компьютеров к сети (десктоп по кабелю, ноутбук по вай-фаю) в обоих случаях в правой части экрана высветился стандартный вопрос "Вы хотите разрешить другим компьютерам и устройствам в этой сети обнаруживать ваш ПК?". В обоих случаях я выбирал "Да". Однако при попытке открыть ветку "Сеть" в Проводнике на обеих машинах вылезла желтая плашка сверху и высветилось стандартное уведомление "Сетевое обнаружение отключено. Сетевые компьютеры и устройства не видны. Включите сетевое обнаружение в центре управления сетями и общим доступом". Вывод: первоначальный запрос об обнаружении при подключении либо относится к чему-то другому, либо тупо не работает.

2) Ткнув по желтой плашке сверху, я разрешил сетевое обнаружение. Результат: и ноутбук, и компьютер увидели только сами себя. Подождал несколько минут, но ситуация не изменилась. Тогда я переименовал обе машины, присвоив им простые и понятные имена (Server и Notebook). После перезагрузки ситуация слегка изменилась: ноутбук увидел и себя, и сервер, а вот сервер по-прежнему видел только себя. Начал разбираться... Оказывается, на десктопе в свойствах подключения (в новомодных Параметрах) был выбран режим частной сети, а вот на ноутбуке стоял режим общедоступной сети. По всей видимости, Майкрософт считает, что подключение по кабелю бывает только в домашних условиях, а вай-фай есть лишь в общедоступных местах... После переключения ноутбука на режим частной сети десктоп наконец-то его увидел, причем даже ничего обновлять не пришлось, ноут через ~30 секунд сам появился в окне сетевого окружения на десктопе, никаких кнопок я нигде не нажимал.

3) Решил, что Server - это слишком круто для обычного компа и снова переименовал его, на этот раз просто в Desktop. Перезагрузил комп после переименования... И вот тут меня ждал первый крупный облом: на ноутбуке по-прежнему в сетевом окружении висел Server, а не Desktop, а на самом десктопе в сетевом окружении вообще было пусто. Перезагрузил обе машины опять, подождал пару минут после входа на рабочий стол и открыл сетевое окружение. Результат: ноутбук видит и Desktop, и Notebook, а вот десктоп видит только Notebook, явно не подозревая о собственном существовании. ))) Попытка обновить (F5) статус сетевого окружения привела к тому, что десктоп потерял в итоге и ноутбук. М-да... Самое смешное, что при всем при этом ping по имени успешно выполняется на обеих машинах. Повторная перезагрузка десктопа также ни к чему не привела, он по-прежнему не видит ни себя, ни ноут, в то время как ноут видит и себя, и десктоп. Проверил, кстати, версию о кириллице. На десктопе специально создал пользователя на русском с длинным именем и пробелами: "Юзер Номер Два". Именно так, да. Ну и пароль ему простенький присвоил (123). Попробовал зайти на десктоп с ноутбука - тот спокойно скушал такое имя и пароль. Правда, никаких папок у меня на десктопе расшарено не было, но это уже не принципиально. Главное, что кириллица и пробелы в имени пользователя точно ни на что не влияют.

4) Выключил десктоп вообще. В сетевом окружении на ноутбуке он по-прежнему виден. Подождал пару минут, обновил (F5) окно сетевого окружения, но ноутбук упорно считает, что десктоп в сети. Ладно, включил десктоп обратно и в настройках электропитания отключил функцию быстрого запуска. Снова выключил десктоп, на этот раз это было полноценное завершение работы. И... Снова ноутбук считает, что он все еще в сети. Обновление (F5) ситуацию не меняет. Даже попытка зайти на (уже выключенный) десктоп приводит лишь к типичной ошибке "не найден сетевой путь", однако ноутбук упорно не желал убирать десктоп из сетевого окружения.

6) Пришлось в итоге перезагрузить ноут и только после этого он соизволил убрать десктоп из своего сетевого окружения.

7) Включил снова десктоп и стал ждать что же покажет ноутбук в своем сетевом окружении. Нигде ничего не трогал и не нажимал. Увы, но даже через несколько минут ожидания ноутбук так и не увидел десктоп. Десктоп же вообще не видел ни ноут, ни себя.

Вердикт: даже в самых идеальных и стерильных условиях сетевое окружение в Windows работает просто отвратительно.

Avatar-Lion, по поводу пункта 2- у меня было на одном сервере 2016, после внезапного отключения он частенько ставил тип сети -"общественная" вместо "доменная", и не работало ничего, разве что локально по RDP удавалось зайти. Решения, найденные в интернете, не помогли.
а в имени папки? На 7-ке, да и на 10-ке проблем не помню, но это в стандартной конфигурации.
По поводу пункта 4 - вроде надо перезапустить службу "Обозреватель компьютеров" на клиенте, но это на 7ке, на 10-ке "дохлые" компы убираются по-другому (лень искать :biggrin: )
ПС. с вердиктом согласен на 200%, в старых версиях заморочек с сетью было поменьше.

Создал сейчас новую папку и оставил ей ее стандартное имя (Новая папка). Расшарил. Да, заходит в нее без проблем и файлы с русскими именами также создаются без проблем.

Службы и так перезапускаются при перезагрузке ПК. Дело точно не в этом.

P.S. Ситуация все та же: ноут видит и себя, и десктоп, а десктоп не видит ни себя, ни ноут. Да уж...

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

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

на тему не видения - где-то был параметр частоты обновления кеша днс и кеша имен в окружении.. склероз совсем меня победил, не помню параметры, помню только ipconfig /flushdns, ipconfig /release, ipconfig /renew
короче, возможно, по дефолту разное время жизни кеша, вот и разный итог

Нет, SID - это совсем про другое...

Да, у команды NbtStat есть похожие ключи, но у меня руки пока еще не дошли проверить их эффективность.

Привет всем ребята!

Группа у меня одна, кириллица исключена!

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

Спасибо всем большое за попытку помочь!

dmitryst, сносить Винду по каждому чиху - это не профессионально. Да и потом... Кто сказал что переустановка решает все проблемы? Я сегодня с утра включил свою тестовую сеть из компа и ноута. Безрезультатно, десктоп по-прежнему не видит ни себя, ни ноут в сетевом окружении. Т.е. система изначально имеет какой-то крупный изъян, который нужно научиться решать.

Если пока не снесли, покажите разделы:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

Гостя отключите.
Проверьте дату, время и часовой пояс на сервере.

Данный пост не имеет прямого отношения к изначальному вопросу автора темы и носит чисто справочный характер.

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

Исследование вопроса показало, что все дело в типе сети. VPN-соединение, которое использовалось для доступа в рабочую локальную сеть из дома, было создано с режимом "общественная сеть". При этом у него в свойствах нет стандартного переключателя на "частную сеть" как у обычных сетевых соединений. Пришлось менять через PowerShell:
Первая команда позволяет узнать индекс нужного подключения, а вторая меняет тот самый режим сети. Сразу после этого общая папка спокойно открылась без требования ввести имя пользователя и пароль.

Началось оно еще с Windows Vista, где ввели три типа сетей (домашняя, рабочая, общественная) и где выбор того или иного профиля автоматом включал \ отключал те или иные правила в штатном брэндмауэре Windows. Видимо, решили таким образом позаботиться о простых юзерах, которые не шарят в подобных темах. Ну и админам заодно работу упростить хотели... Наверное. )))

Так-то идея неплохая, ее явно позаимствовали из коммерческих файрволлов, где тоже можно по одному клику переключать профили с набором правил. Другое дело, что по факту ситуация лишь усложнилась, ведь если раньше (WinXP) был некий базовый набор правил и параметров для всех сетевых соединений, стандартный для всех компов (говно-сборки в расчет не берем), то теперь у каждого сетевого соединения свой набор правил и свои параметры сетевого доступа... Так что да, пожалуй, соглашусь: перемудрили.

100%! Ладно бы их не глючило (т.е. один раз зафиксировал доменный профиль, и всё, он железно будет доменным пока не поменяешь сам). У меня из-за этого юзеры не могли заходить на общие ресурсы сервера, я же через RDP заходил без проблем и просто перезагружал сервер, профиль восстанавливался сам. Какую ошибку при этом получали юзеры, я не помню, вроде как таймаут, "но это неточно" :tomato2:
PS. Уж сделали бы как в SELinux - разрешающий, блокирующий и пользовательский режимы.

На видимость компьютеров в сетевом окружении рабочих групп влияет реализация Браузера компьютеров (Computer Browser) в современных Windows. После какого-то обновления, сейчас не вспомню. сетевое окружение стало нормально работать только на одном из компьютеров, который на данный момент являлся главным обозревателем в результате выборов, а поскольку этот процесс случайным, то работоспособное сетевое окружение гуляло по сети от компьютера к компьютеру.
Первоначальным решением было запрещение компьютерам под управлением Windows 10 и 11 участвовать в выборах Браузера сети, и использование в качестве него Windows 7. В такой конфигурации Сетевое окружение стало работать как положено. Для сетей без Windows 7 пришлось искать решение долго и нудно. Как оказалось, главной причиной непредсказуемого поведения сетевого окружения явилось нововведение от Microsoft, связанное с тем, что разработчики Windows применили разделение групп служб svchost.exe, Это разделение выполняется автоматически для систем с более чем 3,5 ГБ ОЗУ. Для систем 3,5 ГБ или менее, службы продолжают группироваться в общий процесс svchost.exe. И это не касается компьютеров в домене - там все осталось по прежнему.
Для блокировки разделения службы, в ее раздел Parameters добавлен новый ключ SvcHostSplitDisable.


Для нормального взаимодействия служб, обеспечивающих сетевое окружение (Lanmanserver и Browser) они должны работать под управлением одного и того же процесса svchost.exe и эта настройка должна быть выполнена на всех компьютерах рабочей группы, поскольку любой из них может стать обозревателем сети в результате выборов.
Ну, и есть еще более простой выход - отменить разделение служб под управлением svchost.exe. Этот вариант более предпочтителен, поскольку разделение служб svchost может привести к кривой работе не только Браузера, но и других сетевых технологий, которые Microsoft посчитала устаревшими и, очевидно, дорабатывать их под концепцию разделения не планирует.

Параметр SvcHostSplitThresholdInKB раздела реестра HKLM\System\Current ControlSet\Control задает размер объема ОЗУ в килобайтах, до превышения которого службы SvcHost будут объединены в группы. По умолчанию он равен dword:00380000 или 3 670 016 Кб ( те самые 3.5Гб, упоминаемые в документации Microsoft). Если, например, задать значение dword:FF000000, то это будет соответствовать 4278190080 Кб, т.е. группировка служб даже для самого современного компьютера будет выполняться всегда.
Команда:
reg add "HKLM\SYSTEM\CurrentControlSet\control" /v "SvcHostSplitThresholdInKB" /t REG_DWORD /d 0xFF000000 /f

Источник - https://ab57.ru/win10net.html
Там же можно скачать bat-файл с полной настройкой рабочего Сетевого окружения.