Hello,
I am not able to map a drive letter to a WebDAV folder under Windows 10. The WebDAV server is provided by a third party on the Internet. The folder name is the same as the username for logging in to the server, so the URL for the WebDAV folder looks like this:
https://drive.webdav.com/user@mail.com/
I can log in through a web browser under Windows 7 and Windows 10.
Under Windows 7 I can map the WebDAV folder to a drive letter with de following command:
> net use z: \drive.webdav.com@SSLuser@mail.com /user:user@mail.com
After submitting the password under Windows 10 this command results in: «System error 53. The network path was not found.»
I have also tried the PowerShell equivalent:
> New-PSDrive -Name Z -PSProvider FileSystem -Root \drive.webdav.com@SSLuser@mail.com -Credential user@mail.com
This also prompts for a password and then results in: «The network path was not found.»
I checked the WebDAV capabilities of the server with the following PowerShell command:
> (Invoke-WebRequest https://drive.webdav.com/user@mail.com/ -Credential user@mail.com -Method Options).Headers.DAV 1,2,<http://apache.org/dav/propset/fs/1>
I used net use and New-PSDrive commands in combination with URL in stead of UNC notation. This lead to different errors. This was to be expected because I understood that one should use these commands in combination with UNC format.
I also tried to replace the server name with the IP address, but this did not solve the problem.
I read that this can be a symptom of the WebClient service not running. I started up ‘services.msc’ and found that the WebClient was running. To make sure it is always running I changed it from starting up manually to automatically. Also this did not solve
the problem.
I read the questions
Unable to map WebDAV over SSL and
Windows webDAV client does not support TLS 1.2. It says the early versions of Windows 10 were not supporting TLS 1.2. My Windows 10 is updated to the recent version 1709, so I did not expect this to be a problem. I checked the TLS 1.2 conversation with
Wireshark while submitting the above New-PSDrive command:
client > server TLSv1.2 255 Client Hello server > client TLSv1.2 1514 Server Hello server > client TLSv1.2 484 Certificate, Server Key Exchange, Server Hello Done client > server TLSv1.2 236 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message server > client TLSv1.2 60 Change Cipher Spec server > client TLSv1.2 155 Encrypted Handshake Message client > server TLSv1.2 395 Application Data server > client TLSv1.2 667 Application Data client > server TLSv1.2 139 Encrypted Alert
From reading the questions I gather that it was not possible to complete the handshake. In this case the handshake is successful. At the end there is an encrypted alert 21. It means that the client could not decrypt a received message. However I repeated
this on the Windows 7 machine and the same package appeared. The only difference is that there are many moer Application Data packages between te handshake and the Encrypted Alert package. But that could be explained by the fact that there the network path
is available followed by exchange of more network packages.
Who has an idea what the cause is of this problem and how it can be resolved?
Cheers,
Henk
Hello,
I am not able to map a drive letter to a WebDAV folder under Windows 10. The WebDAV server is provided by a third party on the Internet. The folder name is the same as the username for logging in to the server, so the URL for the WebDAV folder looks like this:
https://drive.webdav.com/user@mail.com/
I can log in through a web browser under Windows 7 and Windows 10.
Under Windows 7 I can map the WebDAV folder to a drive letter with de following command:
> net use z: \drive.webdav.com@SSLuser@mail.com /user:user@mail.com
After submitting the password under Windows 10 this command results in: «System error 53. The network path was not found.»
I have also tried the PowerShell equivalent:
> New-PSDrive -Name Z -PSProvider FileSystem -Root \drive.webdav.com@SSLuser@mail.com -Credential user@mail.com
This also prompts for a password and then results in: «The network path was not found.»
I checked the WebDAV capabilities of the server with the following PowerShell command:
> (Invoke-WebRequest https://drive.webdav.com/user@mail.com/ -Credential user@mail.com -Method Options).Headers.DAV 1,2,<http://apache.org/dav/propset/fs/1>
I used net use and New-PSDrive commands in combination with URL in stead of UNC notation. This lead to different errors. This was to be expected because I understood that one should use these commands in combination with UNC format.
I also tried to replace the server name with the IP address, but this did not solve the problem.
I read that this can be a symptom of the WebClient service not running. I started up ‘services.msc’ and found that the WebClient was running. To make sure it is always running I changed it from starting up manually to automatically. Also this did not solve
the problem.
I read the questions
Unable to map WebDAV over SSL and
Windows webDAV client does not support TLS 1.2. It says the early versions of Windows 10 were not supporting TLS 1.2. My Windows 10 is updated to the recent version 1709, so I did not expect this to be a problem. I checked the TLS 1.2 conversation with
Wireshark while submitting the above New-PSDrive command:
client > server TLSv1.2 255 Client Hello server > client TLSv1.2 1514 Server Hello server > client TLSv1.2 484 Certificate, Server Key Exchange, Server Hello Done client > server TLSv1.2 236 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message server > client TLSv1.2 60 Change Cipher Spec server > client TLSv1.2 155 Encrypted Handshake Message client > server TLSv1.2 395 Application Data server > client TLSv1.2 667 Application Data client > server TLSv1.2 139 Encrypted Alert
From reading the questions I gather that it was not possible to complete the handshake. In this case the handshake is successful. At the end there is an encrypted alert 21. It means that the client could not decrypt a received message. However I repeated
this on the Windows 7 machine and the same package appeared. The only difference is that there are many moer Application Data packages between te handshake and the Encrypted Alert package. But that could be explained by the fact that there the network path
is available followed by exchange of more network packages.
Who has an idea what the cause is of this problem and how it can be resolved?
Cheers,
Henk
Hello,
I am not able to map a drive letter to a WebDAV folder under Windows 10. The WebDAV server is provided by a third party on the Internet. The folder name is the same as the username for logging in to the server, so the URL for the WebDAV folder looks like this:
https://drive.webdav.com/user@mail.com/
I can log in through a web browser under Windows 7 and Windows 10.
Under Windows 7 I can map the WebDAV folder to a drive letter with de following command:
> net use z: \drive.webdav.com@SSLuser@mail.com /user:user@mail.com
After submitting the password under Windows 10 this command results in: «System error 53. The network path was not found.»
I have also tried the PowerShell equivalent:
> New-PSDrive -Name Z -PSProvider FileSystem -Root \drive.webdav.com@SSLuser@mail.com -Credential user@mail.com
This also prompts for a password and then results in: «The network path was not found.»
I checked the WebDAV capabilities of the server with the following PowerShell command:
> (Invoke-WebRequest https://drive.webdav.com/user@mail.com/ -Credential user@mail.com -Method Options).Headers.DAV 1,2,<http://apache.org/dav/propset/fs/1>
I used net use and New-PSDrive commands in combination with URL in stead of UNC notation. This lead to different errors. This was to be expected because I understood that one should use these commands in combination with UNC format.
I also tried to replace the server name with the IP address, but this did not solve the problem.
I read that this can be a symptom of the WebClient service not running. I started up ‘services.msc’ and found that the WebClient was running. To make sure it is always running I changed it from starting up manually to automatically. Also this did not solve
the problem.
I read the questions
Unable to map WebDAV over SSL and
Windows webDAV client does not support TLS 1.2. It says the early versions of Windows 10 were not supporting TLS 1.2. My Windows 10 is updated to the recent version 1709, so I did not expect this to be a problem. I checked the TLS 1.2 conversation with
Wireshark while submitting the above New-PSDrive command:
client > server TLSv1.2 255 Client Hello server > client TLSv1.2 1514 Server Hello server > client TLSv1.2 484 Certificate, Server Key Exchange, Server Hello Done client > server TLSv1.2 236 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message server > client TLSv1.2 60 Change Cipher Spec server > client TLSv1.2 155 Encrypted Handshake Message client > server TLSv1.2 395 Application Data server > client TLSv1.2 667 Application Data client > server TLSv1.2 139 Encrypted Alert
From reading the questions I gather that it was not possible to complete the handshake. In this case the handshake is successful. At the end there is an encrypted alert 21. It means that the client could not decrypt a received message. However I repeated
this on the Windows 7 machine and the same package appeared. The only difference is that there are many moer Application Data packages between te handshake and the Encrypted Alert package. But that could be explained by the fact that there the network path
is available followed by exchange of more network packages.
Who has an idea what the cause is of this problem and how it can be resolved?
Cheers,
Henk
Hello,
I am not able to map a drive letter to a WebDAV folder under Windows 10. The WebDAV server is provided by a third party on the Internet. The folder name is the same as the username for logging in to the server, so the URL for the WebDAV folder looks like this:
https://drive.webdav.com/user@mail.com/
I can log in through a web browser under Windows 7 and Windows 10.
Under Windows 7 I can map the WebDAV folder to a drive letter with de following command:
> net use z: \drive.webdav.com@SSLuser@mail.com /user:user@mail.com
After submitting the password under Windows 10 this command results in: «System error 53. The network path was not found.»
I have also tried the PowerShell equivalent:
> New-PSDrive -Name Z -PSProvider FileSystem -Root \drive.webdav.com@SSLuser@mail.com -Credential user@mail.com
This also prompts for a password and then results in: «The network path was not found.»
I checked the WebDAV capabilities of the server with the following PowerShell command:
> (Invoke-WebRequest https://drive.webdav.com/user@mail.com/ -Credential user@mail.com -Method Options).Headers.DAV 1,2,<http://apache.org/dav/propset/fs/1>
I used net use and New-PSDrive commands in combination with URL in stead of UNC notation. This lead to different errors. This was to be expected because I understood that one should use these commands in combination with UNC format.
I also tried to replace the server name with the IP address, but this did not solve the problem.
I read that this can be a symptom of the WebClient service not running. I started up ‘services.msc’ and found that the WebClient was running. To make sure it is always running I changed it from starting up manually to automatically. Also this did not solve
the problem.
I read the questions
Unable to map WebDAV over SSL and
Windows webDAV client does not support TLS 1.2. It says the early versions of Windows 10 were not supporting TLS 1.2. My Windows 10 is updated to the recent version 1709, so I did not expect this to be a problem. I checked the TLS 1.2 conversation with
Wireshark while submitting the above New-PSDrive command:
client > server TLSv1.2 255 Client Hello server > client TLSv1.2 1514 Server Hello server > client TLSv1.2 484 Certificate, Server Key Exchange, Server Hello Done client > server TLSv1.2 236 Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message server > client TLSv1.2 60 Change Cipher Spec server > client TLSv1.2 155 Encrypted Handshake Message client > server TLSv1.2 395 Application Data server > client TLSv1.2 667 Application Data client > server TLSv1.2 139 Encrypted Alert
From reading the questions I gather that it was not possible to complete the handshake. In this case the handshake is successful. At the end there is an encrypted alert 21. It means that the client could not decrypt a received message. However I repeated
this on the Windows 7 machine and the same package appeared. The only difference is that there are many moer Application Data packages between te handshake and the Encrypted Alert package. But that could be explained by the fact that there the network path
is available followed by exchange of more network packages.
Who has an idea what the cause is of this problem and how it can be resolved?
Cheers,
Henk
- Remove From My Forums
-
Общие обсуждения
-
Здравствуйте.
Пытаюсь подключить сетевой диск webdav средствами проводника Windows 10 Pro.
Webdav развернут на Windows Server 2019. Это не сервер, а просто файловое хранилище. Домена нет, пользователи локальные, права розданы, по локальной сети все ок работает.
Webdav виртуальный каталог. Адрес в интернете https://*.*.*.*/shares. Сертификат ssl самоподписанный. Базовая аутентификация. Доступ всем пользователям.С Мака сетевой диск подключается, с приложений в смартфоне подключается. В Windows через плагин Total commander подключается, через Internet Explorer (и другие браузеры) – ругается на сертификат, но подключается. Через проводник – никак. Запрашивает
имя пользователя и пароль, указываю корректные, но подключение не происходит: Вход в сеть не произведен. Через командную строку: Системная ошибка 1244. Запрошенная операция не была выполнена, так как пользователь не зарегистрирован.На клиентской машине стоит Windows 10 Pro. Сертификат добавлен в доверенные, служба webclient запущена, параметры реестра аутентификации и доверенных адресов BasicAuthLevel и AuthForwardServerList пробовал изменять, брандмауэр отключал,
параметры безопасности IE снижал – ничего не помогает.Учитывая, что любые сторонние программы и приложения могут без проблем подключаться и работать, я предполагаю, что проблема в клиенте Windows, а не сервере. Задача вроде довольно простая, но никак не могу найти решение.
Помогите советом, или скажите, к кому можно обратиться за помощью в настройке — очень нужно для удаленной работы.
-
Изменен тип
13 июля 2020 г. 7:24
Отсутствие активности
-
Изменен тип
После обновления билда Windows 10 до 1803 или выше (1809, 1903, 1909) некоторые пользователи заметили, что они теперь не могут подключиться к общим папкам сетевым папкам на соседних компьютерах в сети, или к каталогу на сетевом NAS хранилище.
Проводник Windows не может даже отобразить список общих сетевых папок на соседних компьютерах (как с Windows 10, так и с Windows 7). При попытке открыть любую сетевую папку появляется ошибка:
Сетевая ошибка
Windows не может получить доступ к \NAS
Проверьте правильность написания данного имени. В противном случае возможно проблема с вашей сетью. Для определения проблем с сетью щёлкните кнопку «Диагностика».
Код ошибки 0x80070035.
Не найден сетевой путь.
В английской версии Windows 10 эта ошибка выглядит так:
Windows cannot access \share
Error code: 0x80070035.
The network path not found.
При этом с других компьютеров (с более старыми версиями Windows 10, 8.1 или 7), телефонов и других устройств вы можете спокойно открывать и использовать сетевые папки в локальной сети.
Попробуем разобраться, как исправить ошибку с кодом “0x80070035. Не найден сетевой путь” в Windows 10.
Содержание:
- В Windows 10 по-умолчанию отключен протокол SMB v1
- Гостевой вход без проверки подлинности
- Отключение SMB1 и SMB2
- Настройки просмотра сетевого окружения в Windows 10
- Доступ к NAS или Samba хранилищу из Windows 10 с сохранённым паролем
В Windows 10 по-умолчанию отключен протокол SMB v1
В первую очередь нужно понять, связана ли проблема с тем, что в Windows 10 1709 и выше по умолчанию отключен устаревший и небезопасный протокол доступа к сетевым файлам и папкам – SMB v1.0. Если сетевое устройство, к которому вы подключаетесь поддерживает доступ к общим файлам только по протоколу SMBv1 (например, старая версия NAS хранилища, компьютер с Windows XP/Windows Server 2003), то последние билды Windows 10 по-умолчанию не смогут подключиться к сетевым папкам на таком устройстве. И при доступе к ресурсу
\SharedDeviceName
вы можете получить ошибку “0x80070035”.
В Windows 10 вы можете проверить, включен ли у вас протокол доступа к сетевым ресурсам SMBv1 с помощью команды:
Dism /online /Get-Features /format:table | find "SMB1Protocol"
В нашем примере видно, что на компьютере отключен протокол SMB1:
SMB1Protocol | Disabled SMB1Protocol-Client | Disabled SMB1Protocol-Server | Disabled
Вы можете включить клиент для доступа к сетевым устройствам с поддержкой протокола SMBv1 через Панель управления (Программы -> Программы и компоненты -> Включение или отключение компонентов Windows -> Поддержка общего доступа к файлам SMB 1.0 / CIFS -> Клиент SMB 1.0 / CIFS). Можно вызвать окно установки компонентов, выполнив команду optionalfeatures.exe.
Либо вы можете включить клиент SMB 1 командой DISM:
Dism /online /Enable-Feature /FeatureName:"SMB1Protocol-Client"
После установки клиента SMBv1 нужно перезагрузить компьютер.
После перезагрузки проверьте, появился ли доступ к сетевой папке.
Важно! Нежелательно включать поддержку клиента SMB1, а тем более SMB1-Server, т.к. этот протокол является уязвимым и имеет большое количество инструментов удаленной эксплуатации уязвимости. Если вам не нужен протокол SMB v1 для доступа к старым устройствам, обязательно отключите его.
В Windows 10 17090 и выше клиент SMBv1 автоматически удаляется, если он не использовался более 15 дней.
Гостевой вход без проверки подлинности
Если вы используете анонимный доступ к NAS хранилищам или другим компьютерам, нужно включить политику небезопасные гостевые входы. В Windows 1803/1709 она блокирует доступ к сетевым папкам по протоколу SMB 2.0 под анонимным (гостевым) аккаунтом. Для этого нужно в редакторе локальных политик Windows 10 (gpedit.msc) включить политику Enable insecure guest logons (Включить небезопасные гостевые входы) в секции GPO Computer Configuration -> Administrative templates -> Network (Сеть)-> Lanman Workstation.
Или вы можете разрешить сетевой доступ под гостевой записью командой:
reg add HKLMSYSTEMCurrentControlSetServicesLanmanWorkstationParameters /v AllowInsecureGuestAuth /t reg_dword /d 00000001 /f
Отключение SMB1 и SMB2
Если в вашей сети остались только устройства с поддержкой SMB v3 (Windows 8.1/Windows Server 2012 R2 и выше, см. таблицу версий SMB в Windows), вы можете исправить ошибку 0x80070035, отключив SMB1 и SMB2. Дело в том, что ваш компьютер может пытаться использовать протокол SMB 2.0 для доступа к сетевым папкам, которые разрешают только SMB 3.0 подключения (возможно с шифрованием трафика).
Сначала отключите протокол SMB 1 через Панель управления или командами:
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb10 start= disabled
Dism /online /Disable-Feature /FeatureName:"SMB1Protocol"
Затем отключите протокол SMB2.0 в консоли PowerShell:
reg.exe add "HKLMSYSTEMCurrentControlSetservicesLanmanServerParameters" /v "SMB2" /t REG_DWORD /d "0" /f
sc.exe config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc.exe config mrxsmb20 start= disabled
PowerShell -ExecutionPolicy Unrestricted
Set-SmbServerConfiguration –EnableSMB2Protocol $true
Вы можете проверить, что протоколы SMB 1 и SMB 2 отключены, выполнив команду PowerShell:
Get-SmbServerConfiguration | select "*enablesmb*"
EnableSMB1Protocol : False EnableSMB2Protocol : False
Настройки просмотра сетевого окружения в Windows 10
Если ваши компьютеры находятся в рабочей группе, настоятельно советую выполнить рекомендации из статьи Windows 10 перестала видеть сетевое окружение. В частности:
В разделе Network and Sharing Center панели управления на обоих компьютерах проверьте, что в качестве текущего сетевого профиля используется частный профиль – Private (Current profile). Убедитесь, что включены следующие опции:
- Turn on network discovery (Включить сетевое обнаружение) + Turn on automatic setup of network connected devices (Включить автоматическую настройку на сетевых устройствах);
- Turn on file and printer sharing (Включить общий доступ к файлам и принтерам).
В разделе All Networks (Все сети) включите опции:
- Turn off password Protect Sharing (Отключить парольную защиту)
- Turn on sharing (Включить общий доступ)
На обоих компьютерах сбросьте кэш DNS:
ipconfig /flushdns
И перезагрузите оба компьютера.
Что еще стоит проверить:
- В свойствах общей сетевой папки (как на уровне NTFS разрешений файловой системы, так и на уровне сетевой папки) проверьте, что у группы Everyone есть право на чтение содержимого папки;
- Проверьте, открывается ли сетевое хранилище по ip адресу. Для этого в окне проводника наберите \192.168.1.100 (замените на IP адрес вашего сетевого хранилища или компьютера);
- Если у вас на компьютере активно сразу два сетевых интерфейса (Wi-Fi и Ethernet), попробуйте временно отключить один из них и проверить доступ к ресурсам в локальной сети;
- Проверьте, что на вашем компьютере запущены следующие службы (откройте консоль управления службами services.msc). Попробуйте запустить данные службы и переведите их в режим автоматического запуска с задержкой (Automatic Delayed Start):
- Хост поставщика функции обнаружения (Function Discovery Provider Host — fdPHost)
- Публикация ресурсов обнаружения функции (Function Discovery Resource Publication — FDResPub)
- Служба обнаружения SSDP (SSDP Discovery — SSDPSRV)
- Узел универсальных PNP-устройств (UPnP Device Host — (upnphost)
- Служба DNS-клиента (dnscache)
- Попробуйте временно отключить антивирус и/или файервол и проверить, сохранилась ли проблема при доступе к сетевому ресурсу;
- Попробуйте изменить имя компьютера в свойствах системы и после перезагрузки проверить доступ к ресурсам сетевого хранилища;
- Попробуйте отключить IPv6 протокол в свойствах вашего сетевого адаптера в Панели управления;
- Попробуйте выполнить параметров сброс сети TCP/IP командами:
netsh winsock reset
netsh int ip reset - Откройте консоль PowerShell и проверьте доступность удаленного компьютера по сети с помощью командлета Test-NetConnection (возможно доступ блокируется файерволом):
Test-NetConnection 192.168.1.90 -port 445
(если доступ не блокируется, должен появится статус TcpTestSucceeded : True)
.
.Доступ к NAS или Samba хранилищу из Windows 10 с сохранённым паролем
Если проблема возникает только при доступе к сетевому хранилищу NAS (или к Samba серверу на Linux), можно попробовать сохранить пароли для подключения к сетевому хранилищу NAS в менеджере паролей в Панели управления (Credential Manager: “Control Panel” -> “Credentials Manager” -> “Windows Credentials”). Затем в настройках Дополнительных параметров общего доступа включите опцию Использовать учетные записи пользователей и пароли для подключения к другим компьютерам (Use user accounts and passwords to connect to other computers).
Пользователи ПК могут соединить компьютер с операционной системой Windows с другим. Это позволяет совместно использовать ту же сеть, чтобы получить доступ к папкам, файлам, а также другим необходимым вещам по локальной сети или удаленному доступу. К сожалению, некоторые пользователи встречаются «с кодом ошибки: 0x80070035 не найден сетевой путь» при попытке соединиться как гость. Это очень запутанная ошибка. Обычно это происходит, когда сеть функционирует так, как она настроена, но пользователь вводит неправильное имя пути. Каждый путь должен иметь допустимый общий ресурс на удаленном устройстве и иметь разрешение на доступ к тому же ресурсу. Тем не менее разберем по порядку шаги для устранение, когда windows 10/7 не может получить доступ и выдает код ошибки 0x80070035, не найден сетевой путь.
Как исправить ошибку 0x80070035 Не найден сетевой путь
1. Проверьте настройки общего доступа
Прежде всего необходимо убедиться, что ваше устройство правильно используется в сети. Чтобы сделать это, выполните следующие шаги:
- Нажмите правой кнопкой мыши на локальном диске к которому вы хотите получить доступ и выберите «Свойства«.
- Перейдите на вкладку «Доступ«.
- Нажмите «Расширенная настройка«.
- Поставьте галочку «Открыть общий доступ к этой папке«.
- Убедитесь, что выбрали правильное имя диска.
Проверьте решена ли проблема, если windows 10 не может получить доступ и выдает ошибку «0x80070035 не найден сетевой путь», то двигаемся дальше.
2. Совместное использование IP-адреса компьютера
Попробуем обойти ошибку с помощью входа через ip адрес к ресурсу.
- Введите в поиске, около кнопки пуск, cmd или командная строка и запустите от имени администратора.
- Введите в командную строку команду ipconfig /all.
- Узнайте ip адрес компа найдя строку IPv4-адрес 192.168.1.5
- Нажмите теперь сочетание кнопок Win+R и введите //192.168.1.5/F, где F доступ к открытому ресурсу.
Если сетевой путь не найден, и вам выдает ошибку «Вы не можете получить доступ к этой папке…», то шаг 3 поможет вам.
3. Включить гостевые входы
Если у вас в Шаге 2 выдало ошибку «Вы не можете получить доступ к этой общей папке, так как политики безопасности вашей организации блокируют гостевой доступ без проверки подлинности. Эти политики помогают защитить ваш компьютер от небезопасных или вредоносных устройств в сети«, то следуйте ниже, чтобы исправить.
Нажмите Win + R и введите gpedit.msc, чтобы открыть групповые политики. Далее перейдите «Конфигурация компьютера» > «Административные шаблоны» > «Сеть» > «Рабочая станция Lanmann«. Далее, с правой стороны нажмите два раза кликом мыши по графе «Включить небезопасные гостевые входы«, чтобы открыть параметры. В новом окне поставьте «Включено«.
4. Проверка диспетчера устройств
- Нажмите Win+R и введите devmgmt.msc для входа в диспетчер устройств.
- Нажмите вкладку «Вид» и поставьте галочку «Показать скрытые устройства«.
- Далее найдите сетевые адаптеры и раздвиньте список.
- Может быть конфликт со старыми драйверами сетевых адаптеров, которые не удалились с системы. Удалите все ненужные сетевые адаптеры и перезагрузите компьютер, и система установит драйвера на нужные. Более подробно, как удалить старые и скрытые драйвера, если нет кнопки «показать скрытые устройства«.
5. Добавить протокол IPv4 через TCP/IP
- Нажмите Win+R и введите ncpa.cpl для входа в сетевые подключения.
- Нажмите на свое соединение и нажмите правой кнопкой мыши, и выберите «Свойства«.
- На вкладке «Сеть» найдите IP версии 4 (TCP/Ip4) и выделите его мышкой.
- Нажмите кнопку «Установить«.
- Выберите «Протокол«.
- Нажмите «Добавить«.
- Выберите сетевой «Надежный многоадресный протокол (RMP)».
6. Изменение параметров сетевой безопасности
Наконец, вы можете изменить параметр сетевой безопасности, чтобы исправить ошибку «0x80070035 сетевой путь не найден» в Windows 10. Эти шаги заключаются в следующем:
- Нажмите Win+R и введите secpol.msc для входа в локальную политику.
- Перейдите по пути «Локальные политики» > «Параметры безопасности«.
- Найдите справа в поле «Сетевая безопасность: уровень проверки подлинности LAN Manager» и нажмите на него два раза для открытия.
- В новом окне выберите проверку «Оправлять LM и NTLM — использовать сеансовую безопасность«.
Проверьте исправлена ли проблема, когда windows 10/7 не может получить доступ и выдает ошибку «0x80070035 не найден сетевой путь».
7. Включить поддержку общего доступа к файлам SMB 1
Один пользователь упомянул в комментариях, что нужно включить поддержку общего доступа к файлам SMB v1/CIFS. Но Вы должны знать, что Microsoft отказалась от этого компонента из-за безопасности и отключила его в новых версия по умолчанию, как устаревший компонент. На данный момент windows 10 использует версии SMB2 и SMB3. Вы должны понимать, что это временное решение, чтобы получить доступ к папкам и файлов по локальной сети или удаленному доступу. Давайте рассмотрим, как включить SMB1, чтобы дать доступ и исправить ошибку 0x80070035. Также проверим включен ли SMB2/3 и как его включить, если выключен.
- Нажмите Win + R и введите optionalfeatures.exe
- В списке найдите «Поддержка общего доступа к файлам SMB 1.0/CIFS» и поставьте галочку, после чего перезагрузите компьютер.
Руководство к SMB версий 1, 2, 3
Вы наверняка захотите узнать, какая версия установлена на данный момент и как отключить или включить ту или иную версия SMB. Вам нужно запустить PowerShell от имени администратора. Запустить можно в поиске меню пуск, набрав PowerShell. Вставьте следующие команды в зависимости, что Вам нужно:
Протокол SMB версии 1
| Состояние: | Get-WindowsOptionalFeature –Online –FeatureName SMB1Protocol |
| Отключение: | Disable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol |
| Включение: | Enable-WindowsOptionalFeature -Online -FeatureName SMB1Protocol |
Протокол SMB версии 2
| Состояние: | Get-SmbServerConfiguration | Select EnableSMB2Protocol |
| Отключение: | Set-SmbServerConfiguration –EnableSMB2Protocol $false |
| Включение: | Set-SmbServerConfiguration –EnableSMB2Protocol $true |
Протокол SMB версии 3
| Состояние: | Get-SmbServerConfiguration | Select EnableSMB3Protocol |
| Отключение: | Set-SmbServerConfiguration –EnableSMB3Protocol $false |
| Включение: | Set-SmbServerConfiguration –EnableSMB3Protocol $true |
- На скрине ниже я проверил включен ли SMB2 и он мне дал ответ True — Включен, если будет False — отключен.
Ниже один пользователь написал, что при проверке SMB3 выдается ошибка «Set-SmbServerConfiguration : Не удается найти параметр, соответствующий имени параметра «EnableSMB3Protocol«. В этом случае вы вводите команду ниже в PowerShell (от имени админа) и смотрим статусы Smb3: 0-выкл, 1-вкл.
Get-ItemProperty HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters | ForEach-Object {Get-ItemProperty $_.pspath}- Если у вас нет графы SMB3, как на скрине ниже, то введите
Get-SmbServerConfiguration | Select EnableSMB3Protocol - Перезапустите PowerShell от имени администратора и введите команду 1. SMB3 появится у вас в графе. Если значение 0, то введите ниже команду для его активации.
Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetServicesLanmanServerParameters" SMB3 -Type DWORD -Value 1 –Force
Перезагрузите ПК и перепроверьте статус SMB3, включился ли он.
Смотрите еще:
- Резервная копия локальной групповой политики в Windows 10
- Как узнать IP-адрес компьютера
- Как очистить кэш DNS в Windows
- Как сбросить настройки сети
- Как изменить имя профиля сети в Windows
[ Telegram | Поддержать ]
Содержание
- Устранение рассматриваемой ошибки
- Этап 1: Настройка протокола SMB
- Этап 2: Открытие доступа сетевым устройствам
- Этап 3: Отключение протокола IPv6
- Заключение
- Вопросы и ответы
Многие пользователи заметили преимущество сетевых хранилищ файлов, и уже не первый год ими пользуются. Переход на Windows 10 может неприятно удивить ошибкой «Не найден сетевой путь» с кодом 0x80070035 при попытке открытия сетевого хранилища. Впрочем, устранить этот сбой на самом деле достаточно просто.
Устранение рассматриваемой ошибки
В «десятке» версии 1709 и выше разработчики поработали над безопасностью, отчего некоторые доступные ранее сетевые возможности перестали работать. Следовательно, решать проблему с ошибкой «Не найден сетевой путь» следует комплексно.
Этап 1: Настройка протокола SMB
В Виндовс 10 1703 и новее вариант протокола SMBv1 отключён, отчего не выйдет просто так подключиться к NAS-хранилищу или компьютеру под управлением XP и старше. Если у вас именно такие накопители, SMBv1 следует активировать. Первым делом проверьте состояние протокола по следующей инструкции:
- Откройте «Поиск» и начните набирать Командная строка, которая должна появиться первым же результатом. Кликните по нему правой кнопкой мыши (далее ПКМ) и выберите вариант «Запуск от имени администратора».
Читайте также: Как открыть «Командную строку» на Windows 10
- Введите в окно следующую команду:
Dism /online /Get-Features /format:table | find "SMB1Protocol"И подтвердите её нажатием Enter.
- Подождите некоторое время, пока система проверит состояние протокола. Если во всех графах, отмеченных на скриншоте, написано «Включен» – отлично, проблема заключается не в SMBv1, и можно переходить к следующему этапу. Но если присутствует надпись «Отключен», следуйте текущей инструкции.
- Закрывайте «Командную строку» и воспользуйтесь сочетанием клавиш Win+R. В окошке «Выполнить» введите
optionalfeatures.exeи нажмите «ОК». - Найдите среди «Компонентов Windows» папки «Поддержка общего доступа к файлам SMB 1.0 / CIFS» или «SMB 1.0 / CIFS File Sharing Support» и отметьте пункт «Клиент SMB 1.0 / CIFS». Затем нажимайте «ОК» и перезагружайте машину.
Обратите внимание! Протокол SMBv1 является небезопасным (именно через уязвимость в нём и распространялся вирус WannaCry), поэтому рекомендуем отключить его после окончания работы с хранилищем!
Проверяйте возможность доступа к накопителям – ошибка должна исчезнуть. Если описанные действия не помогли, переходите к следующему этапу.
Этап 2: Открытие доступа сетевым устройствам
Если настройка SMB не принесла результатов, потребуется открыть сетевое окружение и проверить, выданы ли параметры доступа: если эта функция отключена, потребуется её включить. Алгоритм такой:
- Вызовите «Панель управления»: откройте «Поиск», начните вводить в него название искомого компонента, а когда он отобразится, щёлкните по нему левой кнопкой мыши.
Читайте также: Способы открытия «Панели управления» в Виндовс 10
- Переключите «Панель управления» в режим отображения «Мелкие значки», после чего кликните по ссылке «Центр управления сетями и общим доступом».
- Слева расположено меню – найдите там пункт «Изменить дополнительные параметры общего доступа» и перейдите к нему.
- В качестве текущего профиля должен быть отмечен вариант «Частный». Затем раскройте эту категорию и активируйте опции «Включить сетевое обнаружение» и «Включить автоматическую настройку на сетевых устройствах».
Затем в категории «Общий доступ к файлам и принтерам» установите вариант «Включить общий доступ к файлам и принтерам», после чего сохраните изменения, воспользовавшись соответствующей кнопкой. - Затем вызовите «Командную строку» (см. Этап 1), введите в нее команду
ipconfig /flushdns, после чего перезагрузите компьютер. - Проделайте шаги 1-5 на компьютере, во время подключения к которому возникает рассматриваемая ошибка.
Как правило, на этом этапе проблема решается. Однако если сообщение «Не найден сетевой путь» всё ещё появляется, переходите далее.
Этап 3: Отключение протокола IPv6
Протокол IPv6 появился относительно недавно, отчего проблемы с ним неизбежны, особенно если дело касается довольно старых сетевых хранилищ. Для их устранения подключение по этому протоколу следует отключить. Порядок действий такой:
- Проделайте шаги 1-2 второго этапа, после чего в перечне опций «Центра управления сетями…» воспользуйтесь ссылкой «Изменение параметров адаптера».
- Затем найдите LAN-адаптер, выделите его и щёлкните ПКМ, после чего выберите пункт «Свойства».
- В списке должен находится пункт «IP версии 6 (TCP/IPv6)», найдите его и снимите отметку, после чего нажмите «ОК».
- Проделайте шаги 2-3 и для адаптера Wi-Fi, если используете беспроводное соединение.
Стоит отметить, что отключение IPv6 может сказаться на возможности доступа к некоторым сайтам, поэтому после работы с сетевым хранилищем рекомендуем заново включить этот протокол.
Заключение
Мы рассмотрели комплексное решение ошибки «Не найден сетевой путь» с кодом 0x80070035. Описанные действия должны помочь, но если проблема всё равно наблюдается, попробуйте воспользоваться рекомендациями из следующей статьи:
Читайте также: Решение проблем с доступом к сетевым папкам в Windows 10
Еще статьи по данной теме: