xxx.xx mb junks found!
Recommend to clean

I got the message above recently on my phone.  A brief search shows the offending app is ES File Explorer.  It seems I and anyone seeing this message with the ability to use a search engine is now uninstalling ES File Explorer.

So…this totally legit looking message popped up on my phone: “267MB Junks on Phone. Recommended to Clean” What should I do?
byu/kyleclements inNexus5

http://forums.androidcentral.com/android-6-0-marshmallow/611585-201-34-mb-junks-found-recommend-clean.html

We have a Dell Studio XPS 9000 which we purchased with an Intel 980x processor back in 2010 for video processing. Over time we’ve added or changed items in this case. In August, we found that 2 of 3 drives in a Raid 0 were failing and one had failed entirely. Luckily the data was in constant churn and was being saved elsewhere as well. When we investigaged, we 55+degC temperatures on two of the drives. The addition of a simple fan and pulling the front cover away from the fan allowed the drives to cool to ~34degC.

The case front is a solid piece of plastic with no airflow. The hard drives are slated to be installed in a location that is poor at best. Unfortunately, airflow was given no consideration here.

Add a Fan and pull front cover away for a massive thermal improvement.

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:

1. JRE_X64_DOWNLOAD_URL=http://download.code42.com/installs/proserver/jre/jre-7-linux-x64.tgz – DO NOT USE
2. JRE_I586_DOWNLOAD_URL=http://download.code42.com/installs/proserver/jre/jre-7-linux-i586.tgz – USE THIS

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:
http://support.code42.com/CrashPlan/4/Getting_Started/Uninstalling_The_Code42_CrashPlan_App

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 ui.properties 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!

Resources:

1. http://support.code42.com/CrashPlan/4/Troubleshooting/CrashPlan_App_Version_4.4.1_On_Linux_Does_Not_Back_Up
2. https://support.code42.com/CrashPlan/4/Configuring/Using_CrashPlan_On_A_Headless_Computer
3. https://community.netgear.com/t5/Backing-up-to-your-ReadyNAS/CrashPlan-Cheat-Sheet-and-Tweaks/td-p/936241

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. http://linuxg.net/how-to-install-oracle-java-jdk-678-on-ubuntu-13-04-12-10-12-04/ . 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 xxx.xxx.xxx.xxx 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.

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:
http://www.dedoimedo.com/computers/windows-10-network-share-access.html

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:
http://www.neowin.net/forum/topic/1261994-fix-windows-10-accessing-network-drives-password-incorrect/

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:
ComputerName\Username
Password

For example, for a drive with everyone permission, it would be:
FileServerName\Guest
blank

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