Mapped Drive will not connect after reboot

Been bashing my head against this for weeks.   

The FQDN v IP address 'fix' works for a day or two, then stops and you have to change to the other method to get it to reconnect, even after removing the drive mappings.   You can't even browse to access the NAS.  There is no Windows server in this network, just five W10 workstations and a NAS, so solutions involving Domain Server/Windows File Server 'fixes' are irrelevant.   I've also discovered that a Linux box plugged into the LAN temporarily has no such issues.  

I've tried re-enabling SMB 1.0 (which I need anyway as our PXE 'server' (on one of the workstations) doesn't play at all without it, so it's back on all of them and the autoremove has been shot in the head.  

Tried the various registry tricks.   At first, they seem to work, then after a few reboot, suddenly it's lost the plot again and nothing short of removing the mappings and reconnecting via IP if it was using FQDN and using FQDN if it was using IP will restore connectivity.   Win 10 20H2 does NOT change this issue in any way, shape or form.  It remains intermittently popping up on reboot.   This has become a major issue as we are in the process of moving user directories (Documents, Pictures, Videos, Desktop and their Outlook .pst file to the NAS.   This has meant several reboots to try and get it to find the desktop!  This is using a full path to the file, not the mapped drive letter, ie //NAS1/Storage/Manager/Desktop not H:\Desktop.  So the underlying network connection to the Synology NAS is not being restored.   

If anyone has suggestions (aside from ditching Windows) I'd be pleased to hear from them.

Geoff

Good!

It has worked for me all the time up until now, and still works, and I have high hopes for it.

Hi!

Thank you for the tip.

My solution with the correction of the date on the NAS only lasted for a few days. :-)

Got another tip now to use the IP Address to the NAS and not the name, and this has worked today. I'll test it for a few more days to see what happens.

This solution worked for me. The mapped network drives remained after a reboot. I'll let you know if anything changes after a few days. My test would be when the NAS goes to sleep and see if the network drives reconnect.

Thanks John,

I had thought about maybe trying a batch file to "remap" the NAS drives at every reboot. However, having not done batch files since DOS days, I didn't know how to proceed. I will certainly try yours, adjusted for my system. But first, how did you arrive at the IP addresses for each network drive? The 192.168 part is clear to me; but how one determines the other two parts isn't. Is it arbitrary, or is there some process to suss out just what they need to be?

Hi Rab,

I use a couple of tools, one is Buffalo's NASNavigator which gives the IP addresses, and I have a MAC address database in EXCEL which I maintain to map known entities.

With the MAC address (which is  the hardware ID of a device's network card) I can map that to the DNS data from my home router. I did this in self defense a few years ago when I noticed that there were unnamed machines on my network. Turns out, they were all legitimate but my Canon printer, for example, doesn't have a name in the DNS tables on my router. I know when I see b8:3e:59:d9:99:1b, OK, that's the printer, no worries.

Anyway, the devices, due to DNS leasing, can change IP addresses. So, I also keep the NAS drive IP addresses static in my router setup, for that, you need the MAC address. Once it is setup, most routers can remember that unless you do a factory reset.

For some reason, using the device or server names (like BUFF2/public) wasn't as reliable as the IP, not sure why WINDOWS gets so easily confused, my LINUX boxes don't.

Cheers,

John

PS - I hope the part about DNS leases helps you setup your environment so you can use the IP addressing for the bat files.

Thanks Andreas,

I'm losing track of who I am replying to; so this reply may also appear elsewhere in the thread. My apologies.

I selected a series of device numbers in my 192.168.1 range that were not close to any of the 15 or so other device IPv4 addresses shown by my router. When I ran that batch file the NET USE /DELETE lines worked - those share are no longer mapped; but the lines to remap, using the selected IP addresses, failed. So I reverted to the original format for NET USE, with the account name and password, that had worked for me when entered manually. It seemed not to work at all, and no NAS shares are now mapped and visible. Some further research indicated that I need to create an "elevated shortcut" for the batch file, to enable it run as administrator in the STARTUP folder. I'm currently learning how to do that. If you have any further advice on this subject, I would be grateful.