![]() ![]()
To I tried to do that: create a whole new share and try to map that, but the same error message pops up, which basically says "the device doesn't exist". Or maybe make a new share and try to connect to that. Redoing the config and rebooting might help. Likely authentication, user ID mapping, or possibly some kind of Samba/SMB protocol negotiation on the NAS. ![]() I am thinking you have cached sessions that are working on some things but they will probably fail eventually too because something on the NAS has stopped working right. I think I would recommend you recreate your share configuration on the NAS, basically remove the share configuration and then redo it after a reboot of the NAS. Meanwhile, I've tried Wireshark to capture anything that would look suspicious when a client tries (and fails) to reach the NAS. That said, all client machines are able to ping the NAS by hostname, and they resolve to the correct IP address each time. Yup, in my case as a home owner, the PiHole is the DNS server, but really it's no more complicated than what the router is doing. Get qfinder link failes how to#I need to learn how to do Split DNS, though, and use that instead.īut most home users have their router as the DNS servers, so that would be my second suggestion to the OP, if DNS is the issue, after trying the IP address directly. You can probably do this with any DNS server and configuring your router right, but this is a piece of cake to do graphically with pfSense. I use pfSense because then I can use NAT reflection to access my local servers by going somewhere like Any new device on my network can automagically be accessed with its hostname as the subdomain, without having to mess with a zone file manually. It's very possible to run DNS through the NAS too so it might be good to have that setup and tell the router to give out the NAS as a/the DNS server for the network. That said, Yes, I have tested to see if using SMBv1 would work, but it didn't make a difference. There is the option to support SMB v1, but I've disabled that since I figured it's not bundled with Windows and therefore isn't needed since almost any modern OS supports SMB v2 and above. So I don't think anything has been upgraded? That is, I don't think the SMB versions have been upgraded since they come built into the OS (Windows and QNAP OS) and aren't likely to be updated frequently.įor the NAS host itself, it is running SMB v2, v2.1, and v3. Get qfinder link failes windows 10#I believe all Windows 10 versions come with SMB v3, and is automatically preferred over SMB 2 (if the host supports it). Get qfinder link failes update#But they are all as up-to-date builds as say April 2021 and newer - I just let Windows update itself, so whatever schedule each machine is on is its own thing. I've also gone to Windows Explorer, "Network", and then double-clicked on the "NAS" object that shows up there, so clearly Windows can see that it exists, but it just doesn't want to communicate with it (via SMB, I'm presuming).Īll my Windows machines are Windows 10 20H2, though some might be one minor build older than others. Both return the same "eh? nothing exists by that name" types of errors. So for example, in Windows (10) I've tried using the "Run" and then \\192.168.1.x as well as Īs (yes, I've named it "nas" to keep things simple). Have you upgraded any of your clients, in other words, are they running a recent version of SMB? (same goes for the NAS) Future visitors from Google-verse, jump to this post to see what I had to run in SSH. UPDATE: Seems that replacing the old SMB config files with the system default (i.e. ![]() The rest return errors that basically says "the network device doesn't exist". Get qfinder link failes android#The devices that are able to connect via SMB: the Macbook when using AFP only, both Android devices and 1 Windows 10 box. A couple of Android devices (running Android 9 and Android 11). Get qfinder link failes pro#I guess client devices are all Windows 10 machines (all running 20H2), a Macbook Pro (Catalina), a Raspberry Pi, and an Ubuntu 20.04 box. Happy to provide more info once I know what to provide. I'm not really sure what info is needed to troubleshoot this further. It seems that these problematic clients just can't see the NAS over SMB. I don't think it's a credentials issue, because I'm able to change the credentials on the working clients just fine. I'm looking for help to troubleshoot SMB issues both in Windows and on QTS. The NAS in question is QNAP running the latest QTS version 4.5.3. I know it's a SMB issue because macOS can connect just fine via AFP:// but fails with smb://. Three devices still have access, others don't.Īs device doesn't exist, even though it can see the device on the network. Not sure how or why, but I've suddenly lost the ability to connect to the NAS via SMBon some client machines. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |