[Box Backup] Failed to setup location

[Chris Wilson]

Hi Pete,

On Tue, 4 Sep 2007, E.W. Peter Jalajas wrote:

> Yes, we are scheduled to try 784 on that client this evening...wish us luck.

Good luck :-)

>>> We tried changing the remote share Path line in bbackupd.conf to 
>>> lowercase, we started getting some weird network errors (109, 67). 
>>> Are you handling case correctly when parsing the Path line?
>>
>> It should be case insensitive. But you said you were already getting an 
>> error 67. How did it change when you changed the case?
>
> Well, we first setup the client bbackupd.conf to not read from the 
> remote share, and it works fine.  We then kill that client (and the 
> client process on the server if it is still running), then add the 
> remote share to bbackupd.conf with a Path like "Z:\dir_name" or "Z:\" 
> (trailing root slash required), restart the service (sometime 
> uninstalling and reinstalling the service), and then we start getting 
> the errors.

So when you use the "correct" case, you get error 67? And what happens 
when you use the "incorrect" case?

Do you get the same kind of errors when you back up the root of the 
filesystem? And do you get them on the root directory itself, the 
directory that was previously failing or some random subdirectory thereof?

Also, please could you try running the backup from the command line 
instead of as a service, to see if you get the same errors? I didn't test 
backing up mounted drives as a service.

>>> Maybe this is a DNS/NetBIOS problem?  We stumbled across this page: 
>>> http://support.microsoft.com/kb/875441
>>>
>>> See the section on "Method 1: Increase the value of the LmhostsTimeout 
>>> registry entry" If you think it might help, let me know and we can try 
>>> to experiment with that.
>>
>> I don't think it's likely, but please feel free to give it a try. Is 
>> the SMB server local or remote to the client running bbackupd?
>
> The two machines are on the same local area network, and, I believe, in 
> the same server room, but I'll double check that tonight.
>
> Just curious, why do you think it is likely not a DNS issue?  BB is 
> reporting it can't see or open a simple share, that we can open with no 
> problems in Windows Explorer?

If it doesn't work from the command line either, when you can access 
it from Explorer, then that mystifies me. But it makes me think that 
Windows is fundamentally able to access the share, which would probably 
rule out an lmhosts/WINS/DNS issue (if my understanding is correct).

> Typing that makes me wonder if we can use an IP address...I can't recall 
> where we stand on Path's containing UNC...

I seem to remember Charles once telling me that drive mappings were local 
to a given user, or were only created when the user logged in, and using 
their login credentials, which would imply that backing up a mapped drive 
as a service was doomed to fail.

I think we agreed that UNC mappings were more likely to work in principle, 
using the Box Backup service's credentials to access the share. But I 
haven't tested that mode yet, either. Will try to do it now.

Thanks for your help and patience in debugging this! I think we all want 
backups of shares to work smoothly, one way or another :-)

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |