Войти

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


Страниц : 1 [2]

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

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

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

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

Avatar-Lion
05-01-2023, 12:40
Наконец-то я доделал кое-что у себя дома и смог провести полноценный эксперимент. Итак, условия:
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 работает просто отвратительно.

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

Avatar-Lion
05-01-2023, 13:38
а в имени папки? »
Создал сейчас новую папку и оставил ей ее стандартное имя (Новая папка). Расшарил. Да, заходит в нее без проблем и файлы с русскими именами также создаются без проблем.

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

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

bredych
05-01-2023, 14:02
bredych, по идее это не должно влиять на возможность авторизации, только на видимость ПК в сетевом окружении. Хотя я вообще не представляю зачем в такой небольшой сети как у ТС делать несколько рабочих групп.
у меня просто изначально возникло подозрение, что юзер на 1 и 2 компе оси понимают как разных юзеров, потому не пускают. Типа сид же разный - значит срать на имя, не пущу. А рабгруппа - для чего-то ведь придумана. мож как раз синхронизация и согласие по именам юзеров, как в домене..

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

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

Avatar-Lion
05-01-2023, 17:09
у меня просто изначально возникло подозрение, что юзер на 1 и 2 компе оси понимают как разных юзеров, потому не пускают. Типа сид же разный - значит срать на имя, не пущу. »
Нет, SID - это совсем про другое...

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

dddimmm
06-01-2023, 13:38
Привет всем ребята!

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

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

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

dmitryst
06-01-2023, 14:30
снесу на днях винду »
ИМХО, так и надо было сделать с самого начала, уже всё и настроили бы без суеты и головняка ;)

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

dmitryst
06-01-2023, 14:55
система изначально имеет какой-то крупный изъян, который нужно научиться решать. »
я лично пока не встречался. В крайнем случае, решается подключением ресурса, как сетевого диска.
сносить Винду по каждому чиху - это не профессионально »
согласен, но в данном случае, там что-то накручено, о чём мы не догадывается, и чистая переустановка поможет, я думаю ;)

Petya V4sechkin
06-01-2023, 19:14
искать иголку в стогу сена больше не собираюсь, снесу на днях винду и переустановлю заново
Если пока не снесли, покажите разделы:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
запись Гостя включена на всякий случай, так же включен общий доступ с парольной защитой
Гостя отключите.
сервер не принимает логин и пароль и запрашивает снова до бесконечности
Проверьте дату, время и часовой пояс на сервере.

Avatar-Lion
03-02-2024, 11:27
Данный пост не имеет прямого отношения к изначальному вопросу автора темы и носит чисто справочный характер.

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

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

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

dmitryst
03-02-2024, 19:59
Avatar-Lion, ИМХО, перемудрили они с этими профилями сети... Зачем они вообще? Ладно, можно бы просто переключить, но нет.. Не первый раз встречал ситуацию, когда профиль сети на сервере слетал с "Доменной" на "общественную" и ничем, кроме перезагрузки, не исправлялся.. На форуме авторов сего поделия я тоже оставил пару постов, но, насколько мне известно, до сегодняшнего дня этот глюк не исправлен.

Avatar-Lion
03-02-2024, 20:27
перемудрили они с этими профилями сети... Зачем они вообще? »
Началось оно еще с Windows Vista, где ввели три типа сетей (домашняя, рабочая, общественная) и где выбор того или иного профиля автоматом включал \ отключал те или иные правила в штатном брэндмауэре Windows. Видимо, решили таким образом позаботиться о простых юзерах, которые не шарят в подобных темах. Ну и админам заодно работу упростить хотели... Наверное. )))

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

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

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

Для нормального взаимодействия служб, обеспечивающих сетевое окружение (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-файл с полной настройкой рабочего Сетевого окружения.




© OSzone.net 2001-2012