I’m still trying to move everything over from my old 1 TB Buffalo Linkstation to a new 3TB My Book Live that I purchased last week.
I started encountering problems copying two large files to a private share, one ~4GB and the other ~7GB. At first they’d copy just fine until the final several MB, then it would stall for a while and even though it would ultimately “complete” the transfer – but the new file wouldn’t be there. I then found this thread:
Sure enough, the private share that I was trying to copy to was connected via WEBDAV, not Windows Network. So I deleted the connection and reconnected to the private share as described in that thread.
Now, however, when I try to copy the files Windows Vista advises:
"There is not enough space on sharename (\mybooklive). You need an additional 201 MB to copy these files.
Space free: 4.10 GB
Total size: 453 GB"
That, however, is completely untrue. According to the MBL UI I’ve only used 787 GB of 3 TB. The old Linkstation is only a 1 TB drive anyway!
Shoot, you’re right, Tony…I hadn’t noticed that. Every time I try to reconnect via the net use command, however, it prompts me for the username and password and then reconnects via Web Client Network. Is there a way to force the share to connect via the Windows Network?
Of interest, I find that it connects to Microsoft Windows Network if I make the share public and reboot the MBL. That of course will work as a temporary workaround in order to transfer the two problem files, as I can then subsequently turn the share back to private, but that leaves sensitive stuff exposed for a period of time and that leaves me uncomfortable. Clearly that’s not an optimal solution.
Try this. Find a service in Vista named “WebClient”, stop it, and try reconnect. Should now connect correctly. Only thing is with what service turned of I think WD2Go is also affected.
I know where it is in Windows XP, not in Vista. Try set the provider order so they are shown in this order . . .
Try this. Find a service in Vista named “WebClient” and try reconnect.
Myron, let’s make sure that I’m understanding you correctly. Yes, I go into Services and I see “WebClient” – it’s showing as Started, with Startup Type Automatic. Are you recommending that I disconnect that service, then try to reconnect to the share via Net Use?
Myron wrote:
Should not connect correctly.
Are you saying that I should set it to not start up automatically?
Myron wrote:
I know where it is in Windows XP, not in Vista. Try set the provider order so they are shown in this order . . .
Microsoft Windows Network
Microsoft Terminal Services
Web Client Network
I’m not readily seeing where to set the preference order.
Start → Settings → Control Panel → Network Connections
Press ALT to display the menu bar, and then on the Advanced menu, click Advanced Settings.
If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
On the Provider Order tab, in the Network Providers list, select the provider that you want to move up or down in the list, and then click the up or down arrow buttons to rearrange the order.
I checked mine and they’re already in this order:
Microsoft Windows Network
Microsoft Terminal Server Network Provider
Web Client Network
So it seems that it should first attempt to connect via Microsoft Windows Network, but private shares are connecting via the Web Client Network instead.
I’m still waiting for the current file transfer operation to finish to try the troubleshooting method that Myron suggested.
Myron, I went into services and made the WebClient service start manually. I rebooted and reset my drive mapping. Voila! The shares connected via Microsoft Windows Network. Thank you!
I’m puzzled, though, at why when the service was enabled it wouldn’t connect via Microsoft Windows Network when that was first in my provider order list.
My win 7 box has the same order, and I’ve never had to modify the service profile. 95% of the time it connects correctly. I can often force it to connect via WebDAV if I monkey around with the URI name, but I have yet to if d the magic combo.
Start → Control Panel → Network Connections → Advanced → Advances Settings… → Provider Order
I don’t fully know why some connections persist via WebDAV. I’ll make a guess.
The Windows OS is already authenticated to the Samba service either as a known user or as a guest. The OS then tries to connect again but it can’t because it’s already authenticated so the Windows OS moves along the provider order list unless one of two things happens.
A network provider connects to the desires resource
No network providers can connect so an error message appears.
thew With WebFolders service disabled the Windows OS can’t connect to anything WebDAV(ish) so the OS only has two options. Connect via. Samba or fail.
The only problem I can envisiage is that WD2Go uses WebDav and the WebFolders service so without that Windows OS service, WD2Go won’t work.
I don’t use WD2Go and don’t need anything that required wht WebFolders service so got that set to manual start-up. I’ve never had an unwantewd WebDAV connection. It’s only happened when I set-up my computer to allow it.
The only problem I can envisiage is that WD2Go uses WebDav and the WebFolders service so without that Windows OS service, WD2Go won’t work.
I just tried it and found that WD2Go still works on the machine where I’ve set WebClient Service to start only manually. However, it appears that logging into the share via WD2Go forced the WebClient Service to reset itself to automatic, for after trying WD2Go I just looked at my services in Windows and WebClient is now reset to start up automatically. I had left it as manual start.
So that’s why WD2Go still worked. Sure enough, running the net use command shows that virtual drive letter established via WD2Go connected via the Web Client Network, and all other shares that were connected locally using Microsoft Windows Network.
I’m still running file transfers so I can’t reboot the machine now, but it will be interesting to see how those private shares reconnect after reboot. I’m hopeful that because those shares are mapped to drive letters as persistent connections, they’ll reconnect via Microsoft Windows Network – but we shall see. If they don’t reconnect that way I guess that I’ll be forced to disable the WebClient Service as my next step in trying to resolve this.