Trying to get the mapped drive access to work properly. I’ve done the steps here (https://www.urbackup.org/faq.html#use_shares), but it’s still giving me difficulty.
Not sure if makes a difference, but server and client are running on same machine (Win server 2008 R2). Both are running as an admin account (services permissions have been set accordingly). -
Cannot get volume for path “Z:”. The system cannot find the file specified. (code: 2)
Cannot access path to backup: “Z:” Errorcode: 3 - The system cannot find the path specified.
This is trying on 2 different shares. One is a network NAS, the other is another windows server. Even tried disabling user access restrictions on both of those shares, and same result.
Probably missing something simple here…
Are you sure the drives are mapped for the user UrBackup is running as?
Personally I might try adding some NET USE commands as a startup task on the server or a similar workaround to ensure they are Windows tends to remap drives “At logon” so if the user isn’t logged on… relying on Windows to have mapped them may fail.
I’m not even at the point of trying to auto-remap drives. I’m just trying to get the initial mapping to work.
And yes, everything is being run under the same admin user.
Well I’m possibly way off beam, as I’m used to working in an AD environment where I can simply give a machine permissions, it’s going back a while remembering network mapping under the more common setup.
Going way back to starting with Win 3.x I still tend to trust command-line more than explorer and would at least be trying
NET USE Z: \\server\share /user:Name password /persistent:Yes
and checking the drive was accessible to Name… then seeing what happened running backups. Under AD Name would become Name@domain.tld in the command cited.
If it failed I might also try just using the UNC path as a target instead of mapping drives, it’d be something to do while waiting for someone who knows more than me to come along…
Your first hint about NET USE didn’t work for me but I’ve succeeded using UNC path!
I’m good with it but it would be convenient to find the final reason for this.
Anyway thank you for your precious advise!
A little update on this. I was kinda able to get it to work via the UNC path, but I was never able to get a complete backup. It’s really slow and then it would say the client goes offline (2 different network shares).
Interesting enough, if I try to set the UNC path via \IPAddress\ it wouldn’t work. If I tried to connect via \ComputerName\ it does work.
@jabramson623 I’m running short on ideas here now, sometimes Windows networking is just troublesome, it’s back to basic troubleshooting since it works some of the time, check your NIC drivers are up to date as step 1, you could try disabling QoS & any other fancy stuff you don’t need in the properties for the connection (adapter settings), sometimes switching mode between offloading being enabled or disabled helps (same property sheet behind the “Config” button), sometimes setting the speed rather than leaving it at Auto, sometimes other things. Always worth checking the cables.
Also worth looking in the event logs & dealing with any networking errors or warnings you find there, that’s caused me much googling of event ID numbers and adjustments to registry values like IRPStackSize in the past for specific misbehaving machines, depends what events you find and what fixes google turns up, fixing those things can’t hurt and might help
I even have one client where I’ve had to limit LAN backup speed for UrBackup to way slower than it does other file transfers, or the NIC driver crashes and kills networking for the entire machine till after a reboot… no idea of the “cause” for that other than “dodgy driver” old hardware no updates to ancient driver available.
Note to self… stick a gigabit card in there and disable the on-board 10/100 in BIOS sometime.
If things behave is often down to your specific config, including exactly what hardware & driver combination you’re using… sorry I can’t point you anywhere specific, it’s down to digging and trying stuff, one step at a time till you find what fixes it… don’t make a ton of changes at once, and revert changes that don’t make any difference…
Mostly these days Windows Networking “Just works” but it’s a nightmare when it “Just doesn’t work quite right”.