Может получить доступ к общему ресурсу Windows по IP или полному адресу, но не по имени хоста

Один из компьютеров лаборатории в школе, которой я управляю, не может получить доступ к каким-либо общим папкам в каталоге \\ ad \ data $. Я могу получить к нему доступ с любого другого компьютера в сети. Если я использую IP \\ 192.168.1.248 \ data $, я могу получить доступ к файлам должным образом. Если я использую полное доменное имя: \\ ad.domain.name \ data $, это также работает. Любой другой компьютер в школе также может правильно обращаться к этой папке.

Когда я пытаюсь получить доступ к общему ресурсу через \\ ad \ data $, я получаю сообщение «У вас нет прав доступа к \\ ad \ data $. Обратитесь к администратору для запроса доступа». Я вошел в систему с учетной записью администратора домена.

Любая идея о том, что может привести к тому, что компьютер с одним доменом не сможет получить доступ к общему ресурсу, к которому он должен иметь доступ?

Сервер работает под управлением Windows Server 2008, а компьютер работает под управлением Windows 7 с пакетом обновления 1 (SP1).

ОБНОВИТЬ

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

У меня только что была похожая проблема.

У нас есть домен и AD, и все домашние папки пользователей настроены в AD.

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

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

Сначала я также подумал, что это проблема DNS.

Читая дальше, кто-то сказал: «попробуй удали кеш CSC», а потом я почти ругался на себя. Зная, что этот ноутбук использовался другим пользователем, который использовал автономные файлы (также их домашнюю папку на том же сервере). Я нашел быстрый способ удалить кэш CSC на Win 7 (намного проще на XP). Перезагрузил компьютер и проблема была решена.

Вот ссылки, по которым я нашел информацию:

http://www.petri.co.il/forums/showthread.php?t=60629

http://support.microsoft.com/kb/942974

Я видел проблему, подобную этой, и она была вызвана тем, что DNS был настроен не добавлять доменное имя автоматически.

Итак, я бы проверил, установлен ли флажок Добавить основной DNS-суффикс и DNS-суффикс, а также Добавить родительский суффикс основного DNS-суффикса .

Это можно найти через

Control Panel\Network and Internet\Network and Sharing Center
Local Area Connection Status
Properties
Internet Protocol Version 4 (TCP/IPv4) and/or Internet Protocol Version 6 (TCP/IPv6) 
Properties
Advanced
DNS

Win7 / server 2008> введите в панели управления «Диспетчер учетных данных» и удалите все сохраненные учетные данные.

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

Используя командную строку:

1. Чтобы увидеть в настоящее время подключенные акции
   net use
2. Удалить соединение, чтобы поделиться Y на xxx.xxx.xxx.xxx
   net use \\xxx.xxx.xxx.xxx\Y /delete
3. Удалить соединение, чтобы поделиться Y на XXX
   net use \\XXX\Y /delete
4. Чтобы удалить подключенный сетевой диск
   net use Y: /delete
5. Чтобы восстановить подключенный сетевой диск
   net use Y: \\xxx.xxx.xxx.xxx\Y /PERSISTENT:YES /USER:XXX\user /SAVECRED

Другим потенциальным подозреваемым является Samsung PC Share manager. После удаления его с хоста проблема исчезла.

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

Это происходит под учетной записью локального администратора, например, имя_компьютера \ Администратор?

Правильно ли выполняется аутентификация компьютера на контроллере домена?

Убедитесь, что вы еще не подключаетесь к \ ad, используя другие (или старые) учетные данные. Я сталкивался с подобными проблемами, когда подключенный диск был подключен к общему ресурсу на сервере с использованием моей «обычной» доменной учетной записи, а затем я попытался подключиться к другому общему ресурсу на том же сервере с помощью моей учетной записи «admin» домена.

Решает ли перезагрузка проблему?

У меня была связанная проблема. У меня была машина XP Home с доступом к общим / общим папкам и дискам на машине с Windows 7. Я играл с настройками рабочей группы / домашней группы в Windows 7 и изменил параметр «Общий доступ, защищенный паролем». Я мог видеть свои общие папки на моем компьютере с XP Home, но не мог читать или записывать из них в / на них. Это сводило меня с ума - потому что когда я создавал нового пользователя на машине с XP Home и обращался к своим ресурсам на машине с Win 7, проблем не было - я мог читать и писать файлы!

Поэтому я вернулся к своей старой (основной) учетной записи пользователя и все еще не мог получить доступ к общим файлам ...

Я испробовал все виды решений - net use * / del и попытался удалить учетные записи пользователей net user / delete - я пытался избавиться от кэшированных учетных данных - но ничего не получалось. Доступ к общим ресурсам через IP-адрес работал! Argggh !!

Я попытался установить рабочую группу на обеих машинах в рабочую группу (XP HOME машина была MSHOME)

В конце концов мне пришлось сменить ИМЯ КОМПЬЮТЕРА на моем компьютере с Windows 7, перезагрузить компьютер, а затем получить доступ к моим общим папкам с компьютера с ОС HOME. Затем он попросил у меня логин пользователя / пароль, который я ввел заново. Однако у меня были пути и прочее, в которых использовалось имя моего старого компьютера, поэтому я затем изменил свой компьютер с Win 7 на прежний. Аллилуиа! Это сработало - снова меня спросили о пользователе / ​​пароле, и я смог получить доступ к своим ресурсам с компьютера XP HOME!

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

Я сталкивался с несколькими похожими проблемами на подобных форумах, но они не такие, как у меня.

У меня была эта проблема после обновления Server 2008 R2 Box до Server 2012 R2 с обновлением. Для меня переход в Диспетчер учетных данных и удаление учетных данных Windows -> Общие учетные данные решили проблему.

В одном из моих случаев, к моему удивлению, оказалось, что мне нужно было очистить кэш DNS в дополнение к включению функции поддержки SMB 1.0 в Windows 8.1. Это был присоединенный к домену компьютер, который был отключен от своего домена.

В другом случае не подключенный к домену компьютер, очистка кеша DNS не помог. Тем не менее, что любопытно, полностью квалифицированное имя \\Name.сработало, когда \\Nameэтого не произошло (я не пробовал этого сына на первой машине). Я не уверен, в чем проблема, но я предполагаю, что это связано с отсутствием доменного имени.

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

Решением было отключить автономную синхронизацию.

Может быть сетевые списки контроля доступа. В одной среде, в которой я работал, они были заменены на порт 445. Итак:

\ Имя хоста \ доля

• Клиент пытался подключиться через SMB через порт TCP / IP 445
• Заблокировано сетевыми ACL
• Клиент не может подключиться

\ Hostname.fqdn \ доля

• Клиент пытался подключиться через SMB через TCP.IP порт 445
• Заблокировано сетевыми ACL
• Клиент подключается через NetBT через порт 139
• Успешное соединение

Так уж получилось, что при подключении к FQDN пытается использовать NetBT, и порт 139 был открыт, поэтому прошло успешно.

Таким решением было разблокировать порт 445.