Windows paylaşımına IP veya FQDN adresiyle erişebilir, ancak ana bilgisayar adına göre erişemez


11

Yönettiğim okuldaki laboratuar bilgisayarlarından biri \\ ad \ data $ dizini altındaki herhangi bir paylaşıma erişemiyor. Ağdaki herhangi bir bilgisayardan erişebilirim. IP \\ 192.168.1.248 \ data $ kullanırsam dosyalara düzgün bir şekilde erişebilirim. FQDN: \\ ad.etkialanı.adı \ veri $ kullanırsam da çalışır. Okuldaki diğer tüm bilgisayarlar da bu paylaşıma düzgün bir şekilde erişebilir.

\\ ad \ data $ ile paylaşıma erişmeye çalıştığımda "\\ ad \ data $ erişim izniniz yok. Erişim istemek için yöneticinize başvurun." Alan adı yöneticisi hesabıyla giriş yaptım.

Tek bir etki alanı bilgisayarının erişmesi gereken bir paylaşıma erişememesine ne neden olacağına dair bir fikriniz var mı?

Sunucu Windows Server 2008 çalıştırıyor ve bilgisayarda Windows 7 SP1 çalışıyor.

GÜNCELLEME

Sorun artık ağdaki diğer birçok bilgisayarda, personel bilgisayarlarında ve öğrenci bilgisayarlarında yaşanıyor. Active Directory sunucusunda ciddi bir sorun olduğunu düşünmeye başladım.


Bu tür bir sorun tam olarak SF'nin tekerlekli evinde olduğu için bir moderatörün sorunuzu ServerFault.com'a taşımasını istemenizi öneririm
Scott Chamberlain

Yanıtlar:


4

Ben sadece benzer bir sorun yaşadım.

Bir alanımız ve AD'miz var ve tüm kullanıcıların ana klasörleri AD'de ayarlandı.

Kullanıcı bir terminal sunucusunda çalışıyor ve ana klasörü iyi çalışıyor Onun için ayarladığımız yeni dizüstü bilgisayarda, sürücü eşlendi, ancak unc aracılığıyla erişmeye çalıştıysanız veya eşlenen sürücüye çift tıklayarak bir hata verdi konum bulunamadı.

Diğer birkaç foruma göz atarken, birisinin giriş klasörüne IP veya FQDN üzerinden erişilip erişilemeyeceğini sorduğunu fark ettim. Bunu denediğimde klasöre erişebiliyordum.

İlk başta bunun bir DNS sorunu olduğunu düşündüm.

Birisi hakkında daha fazla okumak "CSC önbelleğini silmeyi dene" dedi ve sonra neredeyse kendime yemin ettim. Bu not defterinin çevrimdışı dosyaları kullanan başka bir kullanıcı tarafından kullanıldığını bilmek (Aynı sunucudaki ana klasörleri). Win 7'deki CSC önbelleğini silmek için hızlı bir yol buldum (XP'de çok daha kolay). Bilgisayar yeniden başlatıldı ve sorun çözüldü.

Hakkında bilgi bulduğum bağlantılar şunlardır:

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

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


Aynı sorunu yaşadım ve microsoft'un düzeltmesi benim için çalıştı !: support.microsoft.com/kb/942974
joelschmid

3

Bunun gibi bir sorun gördüm ve DNS, etki alanı adını otomatik olarak eklemeyecek şekilde ayarlanmasından kaynaklandı.

Bu nedenle, Birincil ve bağlantıya özgü DNS soneklerini ekle'nin seçili olduğunu ve Birincil DNS sonekinin üst soneklerini ekle işaretlendiğini kontrol ederim .

Bu, aracılığıyla bulunabilir

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

Kontrol ettim ve bu ayar zaten bu şekilde ayarlandı.
Nick

Bir komut istemi açar ve nslookup reklam yazarsanız, nslookup ad.etkialanı.adı yazarsanız aldığınızdan farklı sonuçlar verir mi?
sgmoore

Sonuçlar aynıdır ve bunu yaptığımda nslookup adbana doğru adresle birlikte ad.etkialanı.adını gösterir
Nick

3

Win7 / server 2008> kontrol paneli "Kimlik bilgisi yöneticisi" yazın ve kaydedilen tüm bilgileri silin.


Bunun neden bir fark yaratacağını açıklayabilir misiniz?
soandos

Bu cevabın problemimi nasıl çözdüğü için yeterince minnettar olamıyorum!
MarcH

Denedim ve benim için işe yaramadı. Yanlış / süresi dolmuş kimlik bilgileri nedeniyle bir fark yaratabilir (örneğin şifreyi değiştirdiyseniz).
surfen

2

Aynı sorunu yaşadım (birkaç kez başıma geldi) ve tüm bağlı paylaşımları silerek ve yeniden oluşturarak çözdüm. Aynı konumlara (farklı URL'ler kullanarak) birden fazla bağlantı yapıldı ve sorunların nedeni olduğundan şüpheleniyorum.

Komut satırını kullanma:

  1. Şu anda bağlı olan paylaşımları görmek için
    net use
  2. Xxx.xxx.xxx.xxx üzerinde Y paylaşım bağlantısını silmek için
    net use \\xxx.xxx.xxx.xxx\Y /delete
  3. XXX üzerinde Y paylaşım bağlantısını silmek için
    net use \\XXX\Y /delete
  4. Eşlenen ağ sürücüsünü silmek için
    net use Y: /delete
  5. Eşlenen ağ sürücüsünü yeniden bağlamak için
    net use Y: \\xxx.xxx.xxx.xxx\Y /PERSISTENT:YES /USER:XXX\user /SAVECRED

Bir diğer potansiyel şüpheli Samsung PC Share yöneticisidir. Ana bilgisayardan kaldırdıktan sonra sorun ortadan kalktı.


1

İstemci bilgisayarın kayıtlı kimlik bilgilerini kullanıyor olması mümkündür. Denetim Masası'nın altındaki Windows Kimlik Bilgisi Yöneticisi'ni kullanarak kontrol edebilirsiniz.

Bu bir Yerel Yönetici hesabı altında mı, örneğin makine_adı \ Yönetici?

Makine etki alanı denetleyicisine doğrulanıyor mu?


İstemci bilgisayarda kaydedilmiş kimlik bilgileri yok. Yerel yönetici hesabı, etki alanı hesaplarıyla aynı sorunlara sahip. Makine etki alanı para biriminde oturum açıyor, beklendiği gibi grup ilkeleri uyguluyor.
Nick

0

\ Ad'a farklı (veya eski) kimlik bilgilerini kullanarak bağlanmadığınızdan emin olun. "Normal" etki alanı hesabımı kullanarak bir sunucudaki bir paylaşıma bağlı eşlenen bir sürücüm olduğunda benzer sorunlar gördüm ve sonra etki alanı "yönetici" hesabımı kullanarak aynı sunucudaki başka bir paylaşıma bağlanmaya çalıştım.

Yeniden başlatma sorunu çözüyor mu?


0

İlgili bir sorun yaşadım. Windows 7 makinesindeki paylaşımlara / paylaşılan klasörlere ve sürücülere erişen bir XP Ev makinem vardı. Windows 7'de Workgroup / Homegroup ayarlarıyla oynuyordum ve "Şifre korumalı paylaşım" seçeneğini değiştirdim. Paylaşılan klasörlerimi XP Home makinemde görebiliyordum, ancak onlardan okuma / yazma yapamadım. Beni deli ediyordu - çünkü XP Home makinesinde yeni bir kullanıcı oluşturduğumda ve Win 7 makinesindeki paylaşımlarıma eriştiğimde sorun yoktu - dosyaları okuyabilir ve yazabilirim!

Eski (ana) kullanıcı hesabıma geri döndüm ve yine de paylaşılan dosyalara erişemedim ...

Her türlü çözümü denedim - net use * / del ve kullanıcı hesaplarını silmeyi denedim net user / delete - Önbelleğe alınmış kimlik bilgilerinden kurtulmaya çalıştım - ama hiçbir şey işe yaramadı. Hisse senedine bir IP adresi üzerinden erişim DID çalışması Argggh !!

Her iki makinedeki Workgroup'u Workgroup olarak ayarlamayı denedim (XP HOME makinesi MSHOME idi)

Sonunda, Windows 7 makinemdeki BİLGİSAYAR ADINI değiştirmek, yeniden başlatmak ve daha sonra XP HOME makinesinden paylaşılan klasörlerime erişmek oldu. Sonra tekrar girmiş olduğum bir oturum açma kullanıcısı / parolası istedi. Ancak, eski bilgisayar adımı kullanan yollar ve şeyler vardı, bu yüzden Win 7 bilgisayarımı eski haline geri değiştirdim. Alleluia! İşe yaradı - yine kullanıcı / şifre istendi ve paylaşımlarıma XP HOME makinesinden erişebildim!

Yani, özet: önbelleğe alınmış kimlik bilgileriyle ilgili bir sorun var ve bunları silmenin açık bir yolu yok (kullanıcı hesabındaki Ağ Parolası yöneticisinde hiçbir şey gösterilmedi). Bu nedenle, bilgisayar adınızı geçici olarak değiştirin ve geri değiştirin, bu da bazı sorunları çözebilir.

Bunun gibi forumlarda benzer sorunlarla karşılaştım, ancak hiçbiri benimkiyle aynı değildi.


0

Bir Server 2008 R2 kutusunu güncelleştirmeyle Server 2012 R2'ye yükselttikten sonra bu sorunu yaşadım. Benim için Kimlik Bilgileri Yöneticisi'ne girip Windows Kimlik Bilgilerini kaldırma -> Genel Kimlik Bilgileri sorunu çözdü.


0

Benim durumumdan birinde, sürprizime göre, Windows 8.1'de SMB 1.0 destek özelliğini etkinleştirmenin yanı sıra DNS önbelleğini temizlemem gerektiği ortaya çıktı . Bu, etki alanıyla bağlantısı kesilmiş , etki alanına katılmış bir bilgisayardı .

Diğer durumda, etki alanına katılmamış ve DNS önbelleğini temizleyen bir bilgisayar yardımcı olmadı. Ancak, merakla, tam nitelikli isim \\Name.işe \\Nameyaramadı (Bu oğlu ilk makine denemedim). Burada sorunun ne olduğundan emin değilim, ancak bunun bir alan adının olmamasıyla ilgili olduğunu tahmin ediyorum.


0

Bu işlemi yalnızca belirli bir klasörde yaşadık. Çevrimdışı Klasörler çıkıyor, yeniden yönlendirilmiş klasörler kullandığımız için soruna neden oldu. Bu nedenle Windows, Windows başlar başlamaz bu paylaşıma diğer kullanıcıların kimlik bilgileriyle bağlanıyor, böylece oturum açmış olan kullanıcının bağlantısını reddediyor.

Kullanılan çözüm, çevrimdışı senkronizasyonu kapatmaktı.


0

Ağ ACL'leri olabilir. Çalıştığım bir ortamda, 445 numaralı limanı bloke edecek şekilde değiştirildiler.

\ Hostname \ share

  • İstemci 445 numaralı TCP / IP bağlantı noktasında SMB aracılığıyla bağlanmaya çalıştı
  • Ağ EKL'leri tarafından engellendi
  • İstemci bağlanamıyor

\ Hostname.fqdn \ share

  • İstemci TCP'de IPB üzerinden bağlanmaya çalıştı. IP bağlantı noktası 445
  • Ağ EKL'leri tarafından engellendi
  • İstemci 139 numaralı bağlantı noktasında NetBT aracılığıyla bağlanır
  • Başarılı bağlantı

Böylece, FQDN'ye bağlanmak NetBT'yi kullanmaya çalışır ve 139 numaralı bağlantı noktası açıktı, bu yüzden başarılı oldu.

Böylece çözüm, 445 numaralı bağlantı noktasının engelini kaldırıyordu.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.