Crashplan resolution

Crashplan is a great package. This summer it broke & stopped backing up. It took me a lot of time and another employee a lot of time as we wanted to avoid installing java-common on our production server. This is what we were forced to do in the absence of support from Code42 for headless clients. Later, a Crashplan bug crashed a production server after attempting continuous upgrades and consuming all of the drive space. Both issues are outlined here: Crashplan just crashed my production server.

Today, I found the final resolution. It took hours of trying different solutions, scouring the web, etc. In the end it is simple. The 64bit java package that Code42 supplied did not work on my 64bit Ubuntu 12.04LTS machine. My other linux boxes worked because they were 32bit.

The recommended packages from Crashplan are:


Just dump the above in your crashplan directory and tar xvf it, it creates the jre folder with all the proper user & permissions information. Code42 clearly improved some documentation and their installation since the summer issues.

My Windows desktop Crashplan install upgraded from 3.x to 4.x and stopped working with remote clients as the authentication system changed. The BEST THING you can do is a full uninstall as outlined here:

I was fighting for a long time to get connectivity back to my boxes through my local Crashplan app. Once I did the uninstall, it was again very easy to connect to remote stations. The very short version of what you need to do is:

  1. Close Crashplan
  2. Change the local to port 4200
  3. Change the local .ui_info with the full text key from the remote station .ui_info file. Change the leading port to 4200 on the local file.
  4. Open Crashplan and you are good to go!



Crashplan just crashed my production server

I use a mix of Crashplan and Dropbox. They both have their uses and are great. Until recently that is. My headless linux boxes stopped backing up to Crashplan earlier this year. A local JVM instance wouldn’t run. The documentation for a headless client is poor if you run into any issues. I ended up installing the 12.04LTS java-common package a few months ago which is still v1.6.

Importantly, to do this you must change /usr/local/crashplan/install.vars
From JAVACOMMON=/usr/local/crashplan/jre/bin/java
To JAVACOMMON=/usr/bin/java

I will say that I didn’t install the java package on two other linux servers and they subsequently just worked themselves out. I think Code42 (Crashplan’s creator) was inundated with failures as they released some software which essentially broke their linux based backbone. Their newer software versions, at least after 4.4.1, seem to upgrade the native jre package properly and require little intervention. So, before you go down the road of manual jre installations, look into this first.

Backups started working again after the manual jre upgrade, some hassle, a lot of searching, finding logs, etc. It was a mess. Fast forward to today. Server went down around 1:30am. We look and find there is zero space left on the drive. Damn. We find that in our /usr/local/crashplan/upgrade directory there are effectively an unlimited number of time stamped update folders. Crashplan was creating a new folder every 30 minutes and then finding that v1.6 of the ubuntu java-common package was installed and then failing out of the process. This continued long enough to spool up to our entire drive size. Code42, you need a reasonability check here!

I resolved by uninstalling and finding all crashplan install files and locations. Once removed, I installed java using the guide here and the useful first comment for default install. . I went through the install process again. During the installation process java-common was updated with compliant java files as Crashplan does not work with the Oracle version apparently.

Then we are back up again. I’ve lost a huge time commitment fixing these issues brought about by Crashplan’s upgrade processed from 3.x to 4.x. Prior upgrades were seamless and required no intervention. I only noticed this problem when our backups stopped working and the subsequent failure when we had a production server go down.

The new version also required me to open some ports in the Ubuntu Firewall. ufw allow from to any port 4242 is the command I used to open a port back to my office for backups to go back and forth between servers. I keep a local copy of crashplan data here on a file server for rapid restores if needed.

Windows 10 will not allow network access to our file server and how we fixed it

We have a new Windows 10 machine here, a Dell XPS13 we are setting up. When we get to adding a mapped drive for a network share, we are unable to access the share. It should open with everyone level access. All other workstations and laptops varying from XP, Ubuntu, Win7, Win8 Vista, etc have no trouble accessing this network share. We try the network name, try the ip. We try a variety of authenticated accounts on the computer. No combination of user/pass seems to work. We just get password incorrect messages. What the hell Windows 10?

We turned on the Guest account, which is off by default. That showed some resources across the network but did not resolve the issue with our file server.

We find the following article and follow the steps:

Windows 10 it seems changed the default behavior to access some network resources as a guest. This was not a full resolution.

Then we find the following article and follow the instructions:

After this, we map the drive and go back to disable the guest account and put the registry entry back again.

The full resolution is to enter the following on the username / password prompt when you try to access a network resource in Windows 10:

For example, for a drive with everyone permission, it would be:

Just another daily time burn to find a resolution for this weird issue. Credit to warwagon on

Capital One® Spark® Cash for Business

Well, I tried to leave a review here:

They want to be able to pull vast amounts of social data if I post from google+, facebook, twitter, etc. WordPress and blogger functions simply don’t work. Even if they login, they just take you to your admin page… so here is my review:

3/5 stars

Poor Business Card Practices

We have an account with several cards for our business and a primary user. We had an employee go to another city for a trade show. The charges from that card were deemed fraud and shut down ALL OF OUR OTHER CARDS. This was unexpected and we had to deal with a lot of vendor phone calls that day as we straightened the situation out. There was no fraud and shutting down and entire business credit line for one card number is a poor practice.

In a separate incident, we had actual fraud on one card. We made sure Cap One locked only that one card. They went to re-issue it and for some reason also canceled another card on our account without any notification. When we started getting calls from vendors we called and found that Cap One had canceled the other card by mistake. They also re-issued the card in their standard process rather than the expedited process appropriate for a business our size. 4-6 day handling, then shipping. Issues like this in the past had a replacement card in our hand the NEXT DAY with our competing Amex cards. Cap One expedited the process but could provide no other resolution. Reinstating the old card would have been ideal and saved us time as it was valid, with no fraud, and was already entered into our vendors recurring billing systems.

Lastly, the rewards are poorly managed. We like to take the rewards and put them in a separate account. The only way they offer to do this is by check. We get checks at $200, so we receive several per month. Some have not arrived, we have to keep careful track of these checks mailed by first class mail and this adds unnecessary overhead. ACH or some form of transfer would be an obvious improvement.

We only stay because of the benefits compared to other cards in our purchasing practices. Their poor business handling practices make this hard though as Amex is worlds better at every level other than the rewards offered.

TDK A33 Bluetooth Speaker

TDK A33 Bluetooth Wireless Speaker

I selected a TDK A33 for family a year ago.  Before wrapping it up as a Christmas gift, I connected it and used it to validate this choice.  I was amazed at the sound quality for this small speaker.  I wondered if this was now common and listened to other similar units at Best Buy and over time listened to other friends speakers.  The TDK A33 crushed the equivalent Bose unit with far better mid & high notes while maintaining crisp, clear base.  The Bose was muddy and sounded like something trying to emulate bass.

NOTE:  The A33 is currently for sale for $79.99, an amazing price!

The TDK A34 is now available.  Apparently, it adds longer battery life and improved sound quality.  It is still cheap at $119 currently.

TDK A34 Bluetooth Wireless Speaker

I highly recommend both products while the A33 is currently a great bargain.  When compared to other market options, it is stellar and I highly recommend it.

Quickbooks unrecoverable error in Quickbooks Enterprise 2014

My company used Quickbooks Enterprise (QBE) 2011 until our support was deprecated in May 2014.  We ran the 2011 version as long as possible because we know the upgrade process with Quickbooks is often a huge time sink.   We also understood that QBE 2012 and 2013 suffered from some serious problems and performance issues based on research.  So, when we moved to QBE 2014, we moved carefully with backups and trepidation.  Still, we encountered a major bug which we have not seen listed or resolved after 6 months.  I am blogging about the process to bring attention to this bug with hope for a resolution.  I also hope that QBE support will improve and generally QC at intuit will dramatically improve.  The bug I am highlighting was dramatically worsened by another issue, which is that QBW32.exe rarely closes successfully when closing the software and QBE crashes too frequently.

The bug report we sent to Intuit is below:


 We recently upgraded to QB Enterprise 2014. We have been having recurring issues where quickbooks gives us an unrecoverable error when logging in. We went through QuickBooks tech support and were then forwarded on to the Data Services Group to restore our files to working condition.

 The explanation we were given for the nature of this unrecoverable error that locks us out of our company file is that a window or window(s) were being left open when we closed our file and that this somehow was causing quickbooks to have an unrecoverable error. It turns out the “fix” for this is to hold down the alt key while logging into quickbooks.

 We were told that this was in fact not a bug several times by the person in data services group; however, being locked out of your company file and being presented with a completely vague “unrecoverable error” that the first tier of tech support was clueless about for the “mistake” of “leaving a window open” seems ridiculous at best. This is not an uncommon or rare behavior at all and is certainly not an issue we ever ran into in years of using quickbooks prior to upgrading to 2011. Since receiving our working file back this issue has cropped up once again.

 Please understand that this is a bug. Throwing an unrecoverable error with no details and that your first tier tech support cannot answer because a window is left open (which I again don’t understand how this qualifies as a mistake) certainly seems to fit the description of a bug to me and the software developers on our staff.

 This has caused us to waste an enormous amount of our staffs time this week.

 Please see to it that this is filed as a bug and is resolved going forward. We are aware of the “alt key trick” to get back into the file now but the person we spoke to seemed to think that this was OK to leave as is.

Here is what happened:

Unrecoverable error when trying to login to our file as soon as the interface for quickbooks began loading after logging into the file.

Quickbooks Unrecoverable Error: 14664 59300 is the error we most frequently ran into.  The issue occurred when a user either closed their session or Quickbooks crashed or did not close properly.  So, under either condition we would have major data corruption that locked us out of Quickbooks which is wholly unacceptable.

Our long term resolution to this problem follows:

The process is outlined here. You will want to use the “Don’t save the desktop” option once you get to the correct settings form.

Effectively you go to Edit -> Preferences -> Desktop View (left column of prefs) -> Don’t save the desktop. This will return you to an empty desktop each time you open the company file.

The short term resolution was just to hold the alt key while opening the offending file and close any windows.

We have stayed on the R5 release due to major bugs in an R6 update that persist in R7.  There has been no resolution after 6 months to those existing issues.  Our QBE2014 was a bug riddled time soak.  The labor time spent to resolve the problem far exceeded the software cost and we were forced to upgrade due to payroll and general support deprecation.

QBE support was poorly informed, had a poor process and it took us dozens of hours before we were informed of the basic problem, ability to open an unwindowed file with the alt key and a preferences change.  Our resolution is currently effective and we are once again working effectively.  We will be evaluating other software options prior to our forced 2017 upgrade (3 year support cycle).

The Blogger image circle of death

I went to one of my blogs on Blogger today to pull up an image only to be greeted with the Blogger image circle of death.


My first reaction was WTF?  I check and all my blogs are affected.  I Google search for broken Blogger images and removed Blogger images without much luck.  I did happen to come across a google forum here that helped:!topic/picasa/9ttGjFI6GS4[1-25-false] .  I went to Google Photos under one of my google usernames and did not see the images.  I went into the trash to find them there.  I was able to select and restore all the relevant images.  Luckily, I caught the issue before the trash was automatically removed.

So, why did this happen?  I was purging my phone of images, which I do every 6-12 months, and making sure I had archives on Dropbox.  It turns out the deletion process I selected on my phone removed images “everywhere” including my blog which had never been directly associated with Google Photos.

Bad Google, Bad.  This tenuous connection is having my phone delete blog images I created long before I had “Google Photos” or any associated service?  My desire to declutter my phone breaks my years old Blogger postings?  This should not be.

On the upside it didn’t take too long to figure out, I was lucky, and I lost nothing.  I won’t be using Blogger for any future projects and will note to take care with this silliness.




Comodo marketing for SSL certificates

I have some wildcard ssl certificates with Godaddy on a 3 year interval.  My renewal is two months from now and I have started to receive calls weekly for each individual domain from Comodo offering me savings.  Their pitch is basically to tell me how much it costs to renew ($269.99/yr) and that they will save me a few bucks, something on the order of $50.

I asked them to take me off their call list and explained that Godaddy has inflated pricing and right off the bat will mark down 35% with coupon codes, bringing this number down to $202.49/yr.

Comodo is using domain records to solicit you with persistent, annoying calls that don’t save you money!

River City Racing VIR 24 hour Classic Race Recap

This recap is from the August 9 – 10, 2014 ChumpCar 24 hour race in the #301 River City Racing Nissan 240SX.
The week before the race, many of us were up to 2-3am in the morning each night while going about our normal 9-5 jobs during the week trying to finish the car. A special thanks to Joey for all the effort put in to get us on track!On Thursday night, we stopped working to take the car around the block around 2am. Around 3am the car was loaded on the trailer and the gear was mostly packed. We met at 7am Friday and left with the car and two trailers around 8am after finishing our packing. We arrived at VIR, went through registration and unloaded in the paddock around noon. We went through a pre-race checklist developed for team Biohazard and were able to get the car ready enough for us to feel comfortable for some test laps. Morgan took the car out and soon found high air fuel ratios and saw our temperature quickly rise.

Upon inspection, the engine was clattering heavily and after removing the cam cover to inspect the valvetrain, a bad cam chain tensioner was found. The closest replacement part was 1.5 hours away and David drove to Greensboro and back to retrieve the required part. The part was installed the same night and validated as functioning but our practice time plus engine and clutch break-in time was lost. New air ducting was installed to improve cooling across our tiny oem radiator. As most of the team was new to ChumpCar, most members had to to through gear check-in. Some of the team had never put in hot laps at any racetrack, let alone the very technical and challenging VIR Grand course!

On Saturday morning, the team met around 8am and began to prepare for the event. It was raining heavily and ours was one of the later cars to enter the track. This was good however, as the pace could be kept low to work with a completely new car with many new parts that had never been run before. While the team did think about defogging, thanks to teams Racing Strong Motorsports & Biohazard, a squeegee was the only solution that could be arranged in time for the race start.

The first session in any ChumpCar race is filled with incidents and the consistent rain and green track made this start especially attrition filled. James started the race and took it easy to keep everything together and to debug the car in the mess of the first session. After running for a few, laps it became evident that the fog could not be cleaned fast enough for safely racing at speed! The rear brakes were also found to be FAR to aggressive, leading to lockup in nearly every braking event. A pit stop was taken to install ducting to bring airflow to the rear of the windshield and replace the rear pads. The team did an amazing job and had the pads replaced in just minutes!

The fog solution was completely resolved, unfortunately now, water entered the ducting to the window and on the straightaways, the water spray onto the window leading to visibility problems. Another pitstop later and holes were punched to drain the ducting and a cover was made. The cover later had to be modified to increase airflow but our fogging solution was now resolved and the car was handling well.

Drew was next in the car and did an amazing job. This was Drew’s first time in a racecar on a race course and this was in the rain with a new car in wheel to wheel racing! Drew immediately showed good pace and kept the car together. Each pit stop was slow, around 12 minutes, compared to the 5 minute stops of well practiced teams. This was our first race and modifications were being done each pit stop to improve the car and check on basics like oil level, pad wear, tire pressure, tire temperature, etc.

Kevin was next in the car and was also able to show immediate pace. Kevin is an accomplished autocrosser and this showed through at his first wheel to wheel racing event on a full road course! The course began to dry and Kevin’s times dropped with the conditions. Our clutch began showing slippage through Kevin’s session.

Alex was next in the car and also showed immediate pace. As the course continued to dry out, Alex picked up the pace and continued to set times we weren’t sure the car was capable of. The clutch condition worsened through this session and we found that the closest replacement clutch was hours away. Another cooperative team, #777 Wood is Wonderful, from the Lake Gaston area was able to provide a spare clutch. The team decided to employ a comically unique approach Morgan found. The solution was to mix Coke & flour and put this directly onto the clutch! We joked that if this solution worked, we would have to publish it and tell it to everyone.

David went in at the next pit stop and while the clutch felt better initially, it did continue to slip. David quickly found the pace and with the continually improving conditions, set our fastest time of the day! Another car gave David a bump but only smeared some rubber on our drivers side door, allowing the car to continue. Conditions began to worsen once again as our wet weekend started to get dark, requiring our driving lights be installed at the next pit stop.

Morgan was next in the car and quickly found our lighting solution to be inadequate. Fortunately, Morgan’s skill as a driver enabled him to set excellent times through the difficult and dark conditions which were difficult to see through.

At the end of Morgan’s session, we were happy to have achieved the lofty goal of getting every member of the team a full stint in this wheel to wheel endurance racing series. Luckily, all team members but Morgan were able to drive a full two hours to learn the course before the dark conditions, so we were able to work around our lighting problems.

Through the remainder of the event, the brakes warped heavily due to lack of cooling but later improved. The clutch worsened dramatically to a point of functioning like a CVT and only holding about ¼ throttle on the straights only to come back to full function by the end of the race. Whether by good fortune or a functional coke & flour solution, we will never know.

The car overheated and was brought in by Alex before any serious damage was done! Another bullet dodged by driver awareness from our amazing group. The problem was found, resolved as rapidly as possible and Alex was sent back out on track to complete his session. The remaining sessions saw improving conditions and corresponding lap times where a new fastest time was set by David in the morning and then Morgan during the last session with a forming dry line.

The team managed to get the car put together just in time for the event. The team sailed through technical inspection. The drivers demonstrated excellence across the board in pace, driving in inclement conditions, and especially keeping the driving clean and safe to keep the car in one piece. We received excellent support from friends and family, including Gretchen without whom we would not have had our defogging solution or clutch solution.

Congratulations to everyone involved with River City Racing! The team exceeded every possible expectation and surprised veteran teams across the board by finishing 38th of nearly 100 cars in difficult conditions with no incidents!

Dropbox made a poor choice with their newest Android version

I switched from Verizon to Straightalk on AT&T and reset my phone in the process.  I reinstalled my apps and everything worked fine except Dropbox.  Specifically, the automatic camera upload feature did not work.

So, I look into this in the settings and only find the option to connect to a personal Dropbox.  I have a business / team account with my company. I try to connect this to my Dropbox account and I am told I cannot connect it to the same account.  Crap.  I find this relevant article -> .  The summary is that Business users now need to create their own personal accounts or manually upload the photos.  I contact Dropbox support for a workaround and get the same information.

Here is where it breaks down for me.  I don’t need or want a personal account that makes file management more difficult and obfuscates my data further.  Do I need another email and password and login to access the information I could previously access in one location?  No.  I understand the use case here and I think only having camera upload on by default for personal accounts is wise for the majority.  Allowing a connection from business to personal accounts is also wise for those who want this capability.  However, completely disallowing a business user from using a previously available feature with their higher cost plan is a problem.  There are business users who have legitimate business needs for their cameras with their business Dropbox accounts.  Why completely prevent those users from selecting this option?

Generally, Dropbox is fantastic and it has made a huge improvement at work, at home and for my data management in general.  File revisions are a life saver as well as being able to easily sync between a mix of devices.  This is one of the few times Dropbox has made a design choice that is a genuine disappointment.  I hope they will hear from more business users to understand that this feature should not be specifically and wholly excluded from the business accounts.

Update:  I found a short term resolution.  The version I had installed with this frustrating limitation was v2.4.2 of the Dropbox Android App.  I looked for older versions and found them here: .  I tried v2.4.1 which had the same issue.  I then went back to v2.3.12.10 and was able to restore full function!  I turned off auto-update on this version and will be keeping this version until Dropbox resolves this problem.