Here is the scenario.

 

I mapped a network drive from my unraid server to my Windows computer. It is my T:\ drive.

If reboot my Windows computer (which runs lots of services) it will NOT reconnect to that T:\ drive unless I open up Windows explorer and click on the T: drive.

What happens is if I DO NOT click on the T: drive after my Windows machine reboots the services and programs that need to write to that drive indicate the drive is not available. The only way I get it back is to manually click on the T: in Windows to establish the connection. Then my programs can write to it. I don't know if this is a Windows thing or an Unraid thing, but as before I never had this type issue when using version 4.7. I can reproduce this problems anytime.

 

 

I think that is a Windows issue.  Every time I reboot my main Windows machine (Windows 7 HP), I have to click on each of 3 network drives that are on a networked Windows XP machine, to get rid of the red X on each.

I had the same issue occasionally running FreeNAS.  It is definitely a problem on the Windows end.  Windows XP had more problems then Windows 7. 

 

One thing you might try to set set the Local Master to 'Yes' if you hadn't done it already.  ("Settings", then "SMB")

 

(As a matter of interest, both my self and a buddy had issues getting establishing connections between Vista machines and any XP machine when Vista was first introduced--- MS changed to networking protocols and apparently didn't completely test the home networking with XP machines.  We never did resolve the issues.  Apparently, if the connection worked the first time you attempted it, everything would be fine from there on.  If it didn't work the first time, you were screwed as long as you had that Vista machine.  Luckily, my Vista machine was a laptop and the connection was not essential.  The only really essential connection was to the family laser printer and I changed that printer from a shared printer to a network printer with its own IP address.  )

 

 

I think that is a Windows issue.  Every time I reboot my main Windows machine (Windows 7 HP), I have to click on each of 3 network drives that are on a networked Windows XP machine, to get rid of the red X on each.

 

This becomes a big problem. If the computer reboots automatically and no one is there click on each folder then whatever program/service that tries to access those mappings won't find them. A big issue if you are transferring lots of data and count on it.

I think that is a Windows issue.  Every time I reboot my main Windows machine (Windows 7 HP), I have to click on each of 3 network drives that are on a networked Windows XP machine, to get rid of the red X on each.

 

This becomes a big problem. If the computer reboots automatically and no one is there click on each folder then whatever program/service that tries to access those mappings won't find them. A big issue if you are transferring lots of data and count on it.

 

Yes, I can see where it can be a major problem.  I think the only real solution until MS addresses the issue is to prevent auto-rebooting of Windows computers.  I believe most of the time this occurs when the user accepts the default option of Windows OS (and many other programs) to automatically update.  By turning off auto-updates, the user becomes responsible for checking for updates, and initiating the update sequence.  If rebooting is required (about 99% of the time, it is!), you can do the reboot and reconnect the networked drive(s) manually by clicking on them.  The user can also select the timing and prevent an auto-reboot from interrupting a file transfer(or file generation)  process. 

 

I am quite sure that most of us would not permit an auto-update of our unRAID OS!  Why should we allow Windows to do it?

Here is the scenario.

 

I mapped a network drive from my unraid server to my Windows computer. It is my T:\ drive.

If reboot my Windows computer (which runs lots of services) it will NOT reconnect to that T:\ drive unless I open up Windows explorer and click on the T: drive.

What happens is if I DO NOT click on the T: drive after my Windows machine reboots the services and programs that need to write to that drive indicate the drive is not available. The only way I get it back is to manually click on the T: in Windows to establish the connection. Then my programs can write to it. I don't know if this is a Windows thing or an Unraid thing, but as before I never had this type issue when using version 4.7. I can reproduce this problems anytime.

 

When you say you can replicate this issue, does this mean that the mapped network drives are unavailable on ALL machines on your network once they are rebooted? Are they accessible if you reboot the unRAID server? I would probably close this topic and open a new one under general support if the issue is only happening on one machine as it does sound like a Windows problem rather than an unRAID/5.0-rc issue.

 

If you could test this and reply it would be appreciated, I'm sure a mod could move the topic if you require.

It happens on all computers, only of course after they reboot. Right now I'll chalk it up to a Windows issue, not being able to re-connect to a network share after a reboot automatically. I bet if it was a Windows based server it would re-establish the connections automatically. I can always run an auto-start program that can perform the action manually.

 

Sorry, the message icon is set to DEFECT (SOLVED) but the thumb is still pointing down in the thread list. Right now in the edit message window the thumb points up.