I know how to set up file history backup for a single user on a network. I just create a share, map a drive letter to it, and instruct Windows File History to use that drive letter. But how do I do it when there are four computers, and I don’t want people to see each other’s backups? Making the WDMyCloud shares “private” with a password doesn’t help. That’s because Windows file history can’t be providing WDMyCloud a username and password when it saves the backups, which it does hourly, and without user input…
It would help if there were a way to make a spot on WDMyCloud visible ONLY to one specific computer on the network, But I can’t find a way to make that happen.
If anyone knows a way to use WDMyCloud to maintain file history backups of four computers, without making those backups visible to all of them, please let me know. Thanks.
As soon as you make a share private for a particular login and log into the mycloud using that users login from the PC that is supposed to have access to that share, windows will store those login details in its password repository to access the MyCloud.
Windows File History on that particular PC shouldn’t in theory then need to login to that share as it already knows the login to use to access the MyCloud.
Wullailhut: Thanks, I tried that, but it doesn’t seem to work. Even though I check the Windows box to remember my credentials, I have to reenter them each time I log in to that particular computer. In other words, entering the wdmycloud login details does let me access the wdmycloud, but ONLY for that Windows session. This is a very great nuisance. Any other thoughts?
I added the Username and Password to the Credential Manager as suggested by Bennor, and now I can view, read and write to the applicable share on WDmycloud, thanks! But this has created a different problem. The batch file I’ve used for years to to back up local files to the WDMycloud share (mapped as the Y: drive) no longer works. I get an access denied error - unable to create directory. What happened, and how do I fix it?
It’s probably mapped to a different drive than the one specified in the batch file.
You can:
Change the batch file to use the new mapping.
Unmap the MyCloud drive and re&map it, selecting the drive letter used in the batch file.
Use Windows disk management to change the drive letter for the mapped MyCloud drive.
Solved the problem by backing up everything to a different drive, deleting the share, deleting the user, deleting the Windows credentials, disconnecting the mapped drive, and building everything back up from scratch.
This was particularly maddening because everything looked correct on the surface. I could access everything in the mapped drive from file explorer, but the blasted batch file wouldn’t work - even though the drive letters matched and the batch file had run flawlessly for years. I suspect that the problem was deeply buried in the vagaries of the permissions labyrinth, or the quirks of the xcopy command, or both.
Anyhow, thanks for all the friendly help. Sometimes the best solution is the one you really don’t want to do - demolish everything and rebuild - but it turns out quicker in the long run.
