Не могу зайти на шару windows 7

Обновлено: 05.07.2024

Имеем Wi-Fi-локалку из пяти ноутов. На всех машинах стоит Windows 7.
Проблема в следующем - один из ноутов не может зайти на остальные. Видит их в сетевом окружении, пингует, но при попытке зайти и увидеть их шары выдает ошибку "0х80070035 не найден сетевой путь".

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

В чем может быть проблема и как ее решить? ОСь переставлять не вариант - куча банковского и отчетного ПО, и возможность печатать на расшареный на другом компе принтер (что, по сути, и требуется реализовать) не стоит той головной боли.

Это с одного форума
**********
Браузер компьютеров
Модуль поддержки NetBIOS через TCP
Рабочая станция
и сети должны быть "домашняя", а не "неизвестная" как по умолчанию настраивает виндовс.
**********
Посмотри - в одинаковой ли сети они находятся.
А если так попробовать подключиться \\IP-компа\Принтер Подхватится печать?

Ну да еще желательно, чтоб имя компа на английском. в M$ с wins-ом пожизненные проблемы.

Ну да еще желательно, чтоб имя компа на английском. в M$ с wins-ом пожизненные проблемы.
Это все перепробовал в первые же полчаса гуглежки. Службы работают, сеть домашняя, везде одна и та же. Настройки проблемного компа аналогичны настройкам "здоровых". По "\\IP\имя_принтера" не цепляется.

Поставил Outpost (говорят, стоял тут раньше), выставил все возможные его настройки во всеобщий legalize, но проблема не ушла.

Самое интересное - остальные компы свободно заходят на шары этого, "больного", а он сам на остальные зайти не может никак. Явно косяк в софте (поначалу еще на роутер грешил - там все чисто; и на wi-fi-модуль - но под линухой с LiveUSB все нормально работает) и явно у этого компа, но где именно - ума не приложу :(

Armitage, а комп не подключается к конкретному порту что за "браузинг" отвечает, или вообще глухо (пинг к примеру) ?
А такой атавизм как lmhosts в семёрке сохранился (может он проблему подправит)?

ivan_i_, пинги ходят, что по сетевым именам, что по IP.

Снес Outpost, почистил после него систему его же чистилкой, как рекомендуют, но не помогло.

Сбросил DNS-кэш, winsock - без изменений.
Удалил и заново установил сетевые адаптеры вместе с дровами - аналогично.

А если с машины telnet ip-другого компа на 139 порт то что будет? Облом или завяжутся?
Как дополнение - временно кроссом завяжи два компа - посмотри на реакцию. пробуй другой адаптер. сними с раб. ноута и проверь. бывают такие косяки.
проверь синхронизацию времени. отключи IPv6. глянь в службах относящимся к дом. группе.

А если с машины telnet ip-другого компа на 139 порт то что будет?
Ничего. И пинг вдруг пропал, а потом снова появился после ребута. В остальном перезагрузка ни на что не повлияла.
проверь синхронизацию времени. отключи IPv6. глянь в службах относящимся к дом. группе.
Это все опять же уже на несколько раз перепроверял, не помогает. С других ноутов что-то пересаживать пока не хочется, да и не в железе имхо дело.
Семёрка, не Starter или Home случайно?
На больном и на двух ноутах Ultimate, на двух оставшихся Home Basic.

You have a computer that is running Windows 7 or Windows Server 2008 R2.
You enable the wireless Hosted Network feature to use the Virtual WiFi function on this computer.
You restart this computer without stopping the Virtual WiFi.
You start the wireless Hosted Network again.

In this scenario, a new Microsoft 6to4 adapter is unexpectedly created in Device Manager. Additionally, if you restart the computer multiple times, multiple Microsoft 6to4 adapters are created.

После перезагрузки компьютера служба Plug and Play завершает работу, прежде чем выполнить процедуру, чтобы включить адаптер Microsoft 6to4 для повторного использования. По этой причине адаптер не может использоваться повторно, когда он подключен. Таким образом создается новый виртуальный адаптер.

Этих "адаптеров Microsoft 6to4" там было

260 штук (видно в скрытых устройствах). Удалял их все сидел больше часа, но после этого и установки заплатки от MS для предотвращения создания новых (КВ980486), о чудо, сеть заработала.

В этой статье данная статья предоставляет решения проблемы, из-за которую псевдоним DNS CNAME не может получить доступ к файлам SMB-серверов.

Применяется к: Windows 10 — все выпуски, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 7 Пакет обновления 1
Исходный номер КБ: 3181029

Симптомы

Вы работаете на файловом сервере SMB, например Windows Server. На сервере есть файлы и ресурсы, настроенные с помощью их имени NetBIOS, доменного имени DNS с полной квалификацией (FQDN) и их псевдонима (CNAME).
У вас есть клиент, который работает Windows 7, Windows Server 2008 R2 или более поздней версии Windows.

Если приложение или пользователь использует фактическое имя хранилища (имя NetBIOS или FQDN) для файлов или других ресурсов на сервере, использующем SMB, доступ будет успешным.

Когда приложение или пользователь использует псевдоним CNAME для файлов или других ресурсов на сервере, использующем SMB, и вы пытаетесь подключиться к акции на файловом сервере с его псевдонимом DNS CNAME. Например, вы пытаетесь подключиться к доле на файловом сервере с помощью псевдонима DNS CNAME:

В этом случае вы испытываете следующие действия:

Успешное Windows сервера 2008 R2 или Windows 7.

Открытая папка

\\uncpath недоступен. Возможно, у вас нет разрешения на использование этого сетевого ресурса. Обратитесь к администратору этого сервера, чтобы узнать, есть ли у вас разрешения на доступ.

Ошибка logon. Имя целевой учетной записи неверно.

Причина

Однако при проверке сетевого следа при неудачной установке сеанса SMB сеанса с ошибкой Kerberos KRB_AP_ERR_MODIFIED. Вот пример неудачного запроса на установку сеансов SMB в сетевом следе:

Если имя файлового сервера было разрешено с помощью DNS, клиент SMB привносим суффикс DNS в имя, предоставленное пользователем. То есть первым компонентом SPN всегда будет имя пользователя, как в следующем примере:

Эта попытка не удалась бы для более старых реализации SMB (Например, AIX Samba 3.5.8), которые не могут быть настроены для проверки подлинности Kerberos и не прослушивают порт прямого хоста SMB 445, а только в порту NetBIOS 139.

Если имя файлового сервера было разрешено с помощью другого механизма, например

NetBIOS
Разрешение многофаскальных имен link-local (LLMNR)
Процессы протокола разрешения одноранговых имен (PNRP)

клиент SMB использует предоставленное пользователем имя, например следующее:

Решение

Чтобы устранить эту проблему на файловом сервере с протоколом SMB версии 1, добавьте значение в DisableStrictNameChecking реестр:

Расположение реестра: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
Имя DWORD: DisableStrictNameChecking
Значение DWORD: 1

Не используйте DNS CNAMEs в будущем для файловой серверы. Если вы хотите по-прежнему давать альтернативные имена серверам, вы можете сделать это со следующей командой:
NETDOM COMPUTERNAME/ADD

Эта команда автоматически регистрирует SPNs для альтернативных имен.

Мы не рекомендуем устранять эту проблему для файлового сервера, который не Windows, введя следующие команды в окне командной подсказки на Windows компьютере. Необходимо войти в систему с учетными данными администратора домена. Затем нажмите кнопку Ввод в командной подсказке для регистрации SPN для CNAME устройства хранения файлового сервера Windows на основе:

Если используется кластеризация Windows 2012 г., установите hotfix для клиентов на уровне Windows XP или Windows Server 2003: не удается получить доступ к ресурсу, который находится на Windows Server 2012 основенеудачного кластера .
Если создается CNAME для кластерного имени, к которое подключаются клиенты, необходимо настроить свойства для этого кластерного имени, чтобы оно отвечало на CNAMEs: Настройка псевдонима для кластерной доли SMBс Windows Server 2012 .

Трассировка сети

Чтобы собрать сетевой след, выполните следующие действия:

Откройте окно командной подсказки, введите следующую команду и нажмите кнопку Ввод:

Удалите все существующие сетевые подключения File Server, заверив следующую команду:

Инициализация кэша всех имен путем удаления существующего кэша:

Чтобы удалить кэш DNS, введите следующую команду и нажмите кнопку Ввод:

Чтобы удалить кэш NetBIOS, введите следующую команду и нажмите кнопку Ввод:

Чтобы удалить кэш Kerberos, введите следующую команду и нажмите кнопку Ввод:

Чтобы удалить кэш ARP, введите следующую команду и нажмите кнопку Ввод:

Попробуйте подключиться к сетевой сети, введя следующую команду и нажав кнопку Ввод:

Чтобы остановить сетевой след в неудачном сценарии, введите следующую команду и нажмите кнопку Ввод:

Сбор параметров реестра

Чтобы собрать параметры реестра на файловом сервере, выберите Начните, выберите Выполнить, введите команду в поле Открыть, а затем выберите ОК. Повторите этот шаг для следующих команд:

Файлы параметров реестра (. ВИЧ) сохраняются в папке TEMP на файловом сервере.

Проверка параметров реестра

Проверьте параметры следующих значений реестра на файловом сервере:

Применение hotfixes (сервер и клиент)

Для Windows 7 и Windows Server 2008 R2 применим следующий Windows 7 Корпоративная фикс:

Кроме того, применим следующие горячие фиксы:

Ссылки

Заявление об отказе от ответственности за сведения о продуктах сторонних производителей

В этой статье упомянуты программные продукты независимых производителей. Корпорация Майкрософт не дает никаких гарантий, подразумеваемых и прочих, относительно производительности и надежности этих продуктов.

Windows не может получить доступ к компьютеру в локальной сети. Не найден сетевой путь. Код ошибки:
Windows не может получить доступ к сетевой папке/диску/иному расположению в локальной сети.
Windows не может получить доступ к *Папка или файл*. Разрешение на доступ к *Путь до папки* отсутствует. Обратитесь к сетевому администратору для получения доступа.

Оглавление статьи:

Исправление сетевых ошибок 0x800070035 и 0x80004005

Если Windows не может получить доступ к сетевой папке и выдает ошибки 0x800070035 или 0x80004005, нужно:

Проверка настроек общего доступа

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

В Windows 8 и 10 есть более простой способ поделиться содержимым папки или диска с пользователями домашней группы:

После этого система должна открыть доступ к указанному пути для всех пользователей локальной сети.

Проверка работоспособности службы Сервер

Включение и выключение служб в Windows 7 и 10 происходит в Панели управления:

Настройка свойств сетевой карты

Ошибки подключения к сетевым устройствам с кодами 0x800070035 и 0x80004005 могут быть решены путем выставления настроек сетевого подключения. В настройках сетевой карты нужно снять флажок с протокола iPv6, а также выполнить настройку iPv4. Метод одинаково хорошо работает в Windows 7 и 10 всех версией. Сначала следует попробовать только выключить протокол iPv6, а уже потом выполнять остальные действия, если этот простой способ не помог.

После этого требуется выполнить несколько простых действий в Диспетчере устройств:

Изменения вступят в силу после перезагрузки компьютера.

Настройка Службы компонентов

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

Инструкция по настройке локального доступа через Службу компонентов:

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

Настройки доступа к сетевой папке

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

Просматривать содержимое сетевой папки могут только те пользователи, у которых есть доступ. Это легко проверить:

Если так и есть, то все в порядке. В противном случае требуется добавить новую группу:

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

Make sure that the default admin$ share is enabled on W7X86.

Говорящую, что на удаленной системе не включен общий ресурс именуемый, как admin$. А вот для работы psexec Он очень необходим. Вот сейчас я разберу все действия которые я применил, чтобы активировать данный ресурс на всех компьютерах домена и что будет если этот ресурс будет выключен (на 100%). Если ресурс admin$ выключен то удаленно просмотреть его не удасться, т. е. Запрос вида: \\host\c$ \\host\admin$ не отобразит ничего какими бы административными правами Вы как администратор домена не обладали.

Если такого нет? \\W7X86\admin$

Выгрузить таблицу по всем сервисам системы, чтобы проанализировать в удобном виде какой сервис отвечает за доступ к ресурсам систем Windows:

C:\Windows\system32>wmic /output:"service.html" service list full /format:htable

За доступ к шаре admin$ отвечает сервис именуемый, как LanmanServer

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

C:\Windows\system32>sc config lanmanserver start= disabled

C:\Windows\system32>net stop lanmanserver

Следующие рабочие станции имеют сеансы на сервере:

Продолжить операцию? (Y-да/N-нет) [Y]: y

Следующие рабочие станции имеют на сервере сеансы с открытыми файлами:

Продолжить операцию? (Y-да/N-нет) [N]: y

Пробую открыть admin$ (W7X86\admin$)

$Пробую открыть admin$ (W7X86\admin$)$

или же такое информационное окно:

И соответственно подключиться через утилиту psexec к компьютеру у меня не удасться, а если она запущена:

C:\Windows\system32>sc config lanmanserver start= auto

C:\Windows\system32>net start lanmanserver

То та учетная запись которая обратилась к этому ресурсу, как локального так и удаленного компьютера увидит перечень файлов и каталогов директории c:\Windows\ если обладает Административными правами.

Чтобы в домене ко всем ресурсам можно было обратиться имея права Администратора домена то можно добавить в дефолтную групповую политику домена следующую настройку:

вкладка: General

Startup: Automatic
Service name: LanmanServer
Service action: Start service
Log on as: Local System account

вкладка: Recovery

после нажимаю Apply — OK. Теперь на станциях на которые до этого момента я не мог зайти через \\host\admin$ зайти с правами Администратора домена зайти смогу, но только когда станции будут перезагружены, а за этот момент у меня отвечает политика по ежедневному выключению рабочих станций в целях экономии электроэнергии → GPO_Shutdown

Для проверки применения политики запуска сервиса я выключил службу и перезагрузился, после проверяю как отработала политика:

C:\Windows\system32>sc query lanmanserver

Тип : 20 WIN32_SHARE_PROCESS

Состояние : 4 RUNNING

(STOPPABLE, PAUSABLE, IGNORES_SHUTDOWN)

Код_выхода_Win32 : 0 (0x0)

Код_выхода_службы : 0 (0x0)

Используйте прокси ((заблокировано роскомнадзором, используйте vpn или proxy)) при использовании Telegram клиента:

Поблагодари автора и новые статьи

будут появляться чаще :)

Карта МКБ: 4432-7300-2472-8059

Большое спасибо тем кто благодарит автора за практические заметки небольшими пожертвованиями. С уважением, Олло Александр aka ekzorchik.

Читайте также: