Hoopster

My Windows Crashplan client (version 4.3) will not connect to the Crashplan engine through a Putty SSH session. Like everyone else, it was working fine until this 4.3 update. I have done the following per suggestions in this thread: -Manually updated Windows client to 4.3 64-bit version (prior 4.2 version was also not connecting) -Copied .ui.info from the Crashplan docker ID directory to the Crashplan directory on the Windows desktop -Changed the Crashplan\conf\ui.properties as follows (yes, I uncommented the lines): serviceHost=192.168.1.10 (My unRAID IP) servicePort=4200 -Edited my.service.xml in Crashplan docker to set <serviceHost> field to 0.0.0.0 (It was 127.0.0.1) I did this one at time and tried to connect after each step. Connection to engine still fails. Any ideas? What is the best way to verify that the Crashplan docker engine is also at version 4.3? I did run a check for updates a couple of times from the Docker tab and it reports up-to-date on all dockers including Crashplan. EDIT: Found in the app.log in the Crashplan Log directory that it says the engine version is 4.3. So, I now have a 4.3 client that cannot connect to the 4.3 backup engine.

I am running unRAID v6.01 and the latest version of unMENU works with it just fine. I rarely use anything in unMENU anymore since the new Web GUI is so complete; however, like many I have it installed for emergency situations which, fortunately for me, have not yet occurred in unRAID 6. I used to see frequent web GUI hangs in unRAID 5, but, since moving over to v6 beginning with beta10, I have experienced a GUI hang just once. I have no idea what is causing yours to hang, but, there are several mentions in these forums of the Unassigned Devices plugin being a suspect. Are you running that?

You can see it in the variables on the Advanced View page (upper right corner) when editing the docker config. It's something like webUI_changme (I can't remember as I changed it )

Sorry, I misunderstood your prior post and thought /config was the mistake and that mapping should have been as in previous build. I have now changed container volume mapping to /config and the WebUI is again accessible. Thank you!! Now on to figuring out the server configuration.

Deleted the template in /boot/config/plugins/dockerMan/template-user/my-OpenVPN-AS.xml; removed container (not image); added container again; problem persists and openvpn folder in appdata remains empty. As Macester said, permission issue in creating folder? Funny thing is I had no such issues with his June 13 build of the container. Issues just began with yesterday's build.

Here is a screenshot of what I have mapped:

Remove the container and image, and then clear the config directory (or choose another location). After that it should work and with the rewrite of the docker it should survive upgrades/rebuilds in the future. PS. Do an update in the Community Applications, it was rebuild and updated about an hour ago. Removed container and image, removed entire openvpn folder and subfolders in docker appdata share, reinstalled OpenVPN from Community Applications, set environment variables, rechecked port forwarding in router. Still cannot access WebUI. Here are some things you can check Can you reach the webui locally? ex, https://192.168.1.100:443 or https://192.168.1.100:943? What does the log say? if you click the little notepad icon to the right in the docker tab. Does the appdata/config/ folder pupulate with files/folders? should be two folders in there /config and /logs. BTW i think managed to reproduce the error, Are you useing something like "/mnt/user/appdata/openvpn/"? Try the disk directly instead "/mnt/cache/appdata/openvpn/", does that work? Host path is set to: "/mnt/cache/appdata/openvpn/" and has been on every install of container. However, in the openvpn folder there is NOTHING. It appears completely empty. The log file contains the repeated message: "./run : line 3: /usr/local/openvpn_as/scripts/openvpnas: No such file or directory" Cannot reach webui locally at https://[ipaddress]:443 or https://[ipaddress]:943 or htpps://[servername]:943?

Remove the container and image, and then clear the config directory (or choose another location). After that it should work and with the rewrite of the docker it should survive upgrades/rebuilds in the future. PS. Do an update in the Community Applications, it was rebuild and updated about an hour ago. Removed container and image, removed entire openvpn folder and subfolders in docker appdata share, reinstalled OpenVPN from Community Applications, set environment variables, rechecked port forwarding in router. Still cannot access WebUI.

Same error here OpenVPN container was working yesterday on the June 13 build. At least it was working as far as being able to access the WebUI and poke around in the setup. I had to remove the OpenVPN container today and reinstall it because of something I messed up and wanted to reset the whole thing from scratch. Ever since the reinstall, the WebUI is also inaccessible for me. Stop and restart container does not resolve problem. I am not seeing the other errors being reported here, but, I can't access the WebUI, I get "cannot establish connection the server at [ipaddress]:943" error. Nothing else is using ports 943 or 443.

Thanks Trurl. This is the first container I have added that required variable editing so I was not familiar with that process.

When I added the OpenVPN-AS container from the Community Applications plugin, I see the following docker run command was executed which sets the environment variables for usernames and passwords as the container is built: /usr/bin/docker run -d --name="OpenVPN-AS" --net="host" --privileged="true" -e ADMIN_PASS="changeme_webui_pass" -e VPN_USER1="changeme_vpnuser" -e VPN_PASS1="changeme_user_pass" -e VPN_USER2="changeme_vpnuser" -e VPN_PASS2="changeme_user_pass" -e TZ="America/Mexico_City" -v "/mnt/cache/appdata/openvpn":"/usr/local/openvpn_as":rw mace/openvpn-as How do I change the environment variables to the usernames and passwords I want as per the container description? Notes Environment Variables Define the variables, ADMIN_PASS (WebUI password),VPN_USER1 and VPN_USER2 (VPN user accounts), VPN_PASS1 and VPN_PASS2 (passwords for VPN user accounts). Running the above command again substituting the desired variables values will simply result in the creation of another container.

I have a Kingston Mobilelite G2, Mobilelite G3 and Mobilelite G4. Of the three, only the G2 works and is my currently registered flash device with a unique GUID. The G3 shows up in the BIOS as a Generic USB 3.0 device (The G2 shows up as a Kingston Reader with both slots available to boot - only boots from SD slot), the G3 will not boot at all with my motherboard, so, I do not know if it has a unique GUID. The G4 also shows up as a Generic USB 3.0 device, boots fine from the microSD slot, but does not have a unique GUID and is, therefore, not able to be registered. It is a pity that a good compact flash reader cannot be found (other than the unavailable G2) as it is very, very useful when playing around with configurations and troubleshooting to just pop in a different SD/micro SD card in the G2 reader without having to do all the copying involved with changing configs on a "fixed" flash drive. I can't image Tom will quit supporting the G2. I suppose his statement to not use a card reader has to do with extreme difficulty in finding one that meets the boot/registration requirements. EDIT: Re: Kingston Mobilelite G3, I am an idiot (a fact established long ago). Running make_bootable actually does what it says it does, it makes the flash drive bootable! The Kingston Mobilelite G3 purchased just a few days ago in Mexico does in fact boot UnRAID from the SD card slot and it had a unique GUID which is now registered.

I recently went through the reiserfs ---> xfs transition on my array as well. I got the same results you did, just a list of the contents of the first disk in verify.txt. To "verify" the contents, I ended up doing a directory compare on each disk from Windows to verify that the number of files and size counts were exactly equal. I also spot checked several files in each directory by comparing them, opening them (pictures, videos, movies and TV shows). The array has been in use for several days now since the transition and I have not yet encountered a problem file.

OK, thanks. I have several shares restricted to certain disks and one that uses all current data disks. For example, I have a Pictures share that uses all the current data disks (disk1 - disk4). After the changes, would I need to set that to disk1, disk2, disk3, disk 5? I have a Videos share that uses disk2, disk3, disk4 so that would require a change to disk1, disk2, disk3, correct? And so on with all shares where the contents have moved to different physical disks? EDIT: Perhaps the easiest thing to do would be to change all shares to use all disks (at least the larger ones that already span multiple disks).

OK, I have read through the instructions several times and it all makes perfect sense. I have five data disks in my array and a parity disk. Disk 5 was recently added (formatted as RFS) and is empty. All five data disks are 3TB WD Reds. I have formatted Disk 5 (it was empty as I had not added it to a user share yet) with XFS and am copying the contents of Disk 1 to Disk 5 as per instructions. My planned migration is like this since all disks are identical in size: Disk 1 ---> Disk 5 Format disk 1 XFS Disk 2 --> Disk 1 Format disk 2 XFS Disk 3 --> Disk 2 Format disk 3 XFS Disk 4 --> Disk 3 Format Disk 4 XFS Disk 4 then becomes the extra disk I can add to user shares as needed. My question is what does this do to user shares where I have the current disk 1 ... disk 4 assigned to the shares? Do I need to unassign the disks and reassign the "new Disk 1 (Disk 5)" as Disk 1, etc. after the changes? As you can see, I am not 100% certain about how physical disks, array disk assignments and user shares that use these disk are all related after making these changes. Of course, initial array configuration and share creation all makes perfect sense, but, I am unclear on what happens when contents are moved from one disk to another after changing file system.

OK, I think I have this problem figured out and resolved. It is related to this thread: http://lime-technology.com/forum/index.php?topic=39237.0 Somehow in the creating and configuration of the Crashplan container, I ended up with a user share called ":" that contained an empty /mnt/user directory structure. That and the creation of appdata/Crashplan on disk1 kept disk1 and parity spinning as long as Crashplan was running. Just removing the Crashplan docker and docker.img was not enough. Once I cleaned up the mystery ":" share and recreated docker.img and Crashplan container, things appear to be working normally. Crashplan is currently synchronizing block information, but, Parity and Disk1 are not spinning.

Unless I stop Crashplan, Parity and Disk1 are constantly spinning. In checking out my docker config and Crashplan config, I realized the appdata share had not been set to cache only and that, in fact, Crashplan program files were installed on Disk1/appdata with some files on Cache/appdata. I removed the Crashplan container and files, ran a rmdir -r appdata on Disk1 to get rid of it completely on disk1, verified the appdata share was set to cache only and reinstalled the Crashplan container. With Crashplan running, Parity and Disk1 continue to spin. They will not spin down and stay spun down unless I stop Crashplan. CrashPlan is setup per default config with /config set to /mnt/user/appdata/crahplan and /data set to /mnt/user. What have I done wrong? EDIT: Since Crashplan was my only installed docker so far, I deleted it and the docker.img file. At least with Crashplan and docker completely gone, I can manually spin down disks and they stay spun down (Parity and Disk1 would spin back up with Crashplan installed). I have no idea why Parity is spinning up in the first place since I am not writing to the array. All disks eventually spun down per disk settings. I"ll check all settings before reinstalling Crashplan docker. I am first trying to eliminate everything else as the cause.

I set the container volume to /mnt and selected backup locations based on share names rather than disks (didn't show anyway). This caused Crashplan to warn me that I was removing files from the backup archive and that they would be permanently deleted. I went ahead and confirmed thinking I was about to delete my entire 2.8tb worth of backup and start over. However, Crashplan recognized the files as already backed up without a change in folder structure and simply rescanned existing files (still took many hours) and backed up a few new files that had been added. After about 18 hours it was done.

I upgraded yesterday from v5.06 to v6b14b. Upgrade went very smoothly with no issues. I am now trying to setup Crashplan docker. I have ~2.8TB data already backed up to Crashplan Central. When I setup the Crashplan container with /data path set to /mnt/user/ and adopted the previous backup set, the Crashplan GUI shows all backed up files as "missing." I have pictures, videos, movies etc. to backup and each of these shares spans 2 or more physical disks. In my prior configuration in the Crashplan GUI I had to expand DISK1, DISK2, DISK3, etc. and select the corresponding directories that contained the data to be backed up for each backup set. With /mnt/user/ specified as data path, the disks and directories do not expand in the same fashion (in fact, I can not drill down to directories that are part of the share in this way) and everything is reported as missing. The /data node expands to the share names, but if I include these, Crashplan wants to remove everything I have already backed up and start over as it is a path change and thinks everything is "new.". Generalz responded that he had set /data to /mnt/user/:/mnt/user/:rw to have Crashplan continue backing up existing data sets. When I do this, Crashplan will not install successfully and the container is removed saying this is an invalid path. I tried adding /data paths for each of the physical disks. The result was the same as setting /data to /mnt/user/ Any ideas for proper /data configuration that will allow Crashplan to continue on with prior configuration? I don't use this docker, but it sounds like you and the people you are quoting are confused about volume mappings. Maybe post what you have for volume mappings and we can help figure it out. It also sounds like you must have had Crashplan set up before to use disk shares instead of user shares. You can't get to the disk shares from /mnt/user. Maybe try /mnt instead. Yes, I am sure I am confused, happens quite often! Here is the Crashplan Docker configuration with /data set to /mnt. It shows the physical disks in the array and looks like it should work: Below is how Crashplan sees things. Note that I had to drill down under physical disk names to select backup folders. Perhaps this was simply an error on my part in setting the original backup set folders and I could have/should have done it under user shares (don't recall if that was something I could have done a couple of years ago when I defined these). Under Mnt it only shows disk1 and disk 2 and they are not expandable. I see the disk and share names under the data node, but, selecting this causes Crashplan to discard the prior backup files and start over. Under User I see the UnRAID share names and this is probably the preferred way of selecting files to backup as it is not physical disk dependent, but, this also results in Crashplan wanting to discard prior backup. As seen in the Crashplan GUI, the Pictures share is currently storing files on disk1 and disk2 (although in UnRaid config it can span disk1..disk4; Videos is on Disk2 and Disk3 (also set to disk2...disk4) and Movies and TV are both on Disk 4. Disk 5 was recently added and currently has nothing on it.

I upgraded yesterday from v5.06 to v6b14b. Upgrade went very smoothly with no issues. I am now trying to setup Crashplan docker. I have ~2.8TB data already backed up to Crashplan Central. When I setup the Crashplan container with /data path set to /mnt/user/ and adopted the previous backup set, the Crashplan GUI shows all backed up files as "missing." I have pictures, videos, movies etc. to backup and each of these shares spans 2 or more physical disks. In my prior configuration in the Crashplan GUI I had to expand DISK1, DISK2, DISK3, etc. and select the corresponding directories that contained the data to be backed up for each backup set. With /mnt/user/ specified as data path, the disks and directories do not expand in the same fashion (in fact, I can not drill down to directories that are part of the share in this way) and everything is reported as missing. The /data node expands to the share names, but if I include these, Crashplan wants to remove everything I have already backed up and start over as it is a path change and thinks everything is "new.". Generalz responded that he had set /data to /mnt/user/:/mnt/user/:rw to have Crashplan continue backing up existing data sets. When I do this, Crashplan will not install successfully and the container is removed saying this is an invalid path. I tried adding /data paths for each of the physical disks. The result was the same as setting /data to /mnt/user/ Any ideas for proper /data configuration that will allow Crashplan to continue on with prior configuration?

Thanks for this. I too need a sleep script for version 5.0 final since it disappeared from the main page in the new interface. I was using SF prior to upgrading to v5.0 final, but, SF has display problems with this release. I know some just leave their serving running 24x7; I do not want to do that as it is lightly used right now. I have modified the unmenu sleep script on the user scripts page such that it now works properly with v5.0 final and I now have a manual sleep button that works great. With your modified Bagpuss auto sleep script, do you put it in your go file so it is active on boot up or do you run it elsewhere? Just curious as to how you are invoking it. I am a total Linux script noob so, I am trying to wrap my head around what the the script is actually doing as far as checking NIC activity and the amount of inactive time before sleep is invoked, but, I very much appreciate the work you and Bagpuss have done on this.

Thanks, I have downloaded wolcmd and modified it with the MAC address of my NIC and the appropriate IP and subnet mask addresses. Even though the NIC supports WOL, it appears my BIOS may not; however, my concern at the moment has more to do with automating the server sleep function before I move on to waking it up. Speeding_Ant's Simple Features Sleep button works great, but, I don't know the code behind it to try it in a script.

The nature of my unRAID server is that it is (for the moment) strictly a media server. I store photos, videos, movies and music on it that does not always need to be accessed. I want to put my unRAID box to sleep automatically after the disks spin down and wake it again when it is needed. I am running v5 beta 14. The sleep script on the wiki page uses "echo 3> /proc/acpi/sleep" which does not put the server in an s3 sleep state with the latest kernels. I have Simple Features installed and the "Sleep" button works perfectly. Is there anyway to modify the sleep script to use whatever method Simple Features is using to sleep the server 5 minutes after disk spin down? This question seems to have been asked before, but, I do not see a definitive answer in this thread. It is likely this has been answered and I just missed it. If so, I apologize in advance for the reading comprehension fail. After I get the sleep portion reliably working, I'll tackle the WOL. Right now, I can successfully wake the server by pressing the blinking power button, by specific keyboard command or a specific time of day. Eventually, the preferred method is WOL though a magic packet. ethtools eht0 shows that "pumbg" is supported and wake is set to "g" so this indicates the NIC supports WOL, correct?

Just to add a clarification, because it may be confusing to some that a drive seems to be working fine, yet the SMART report says it has FAILED. Part of the idea behind the development of the SMART system is to try to alert users to imminent failure BEFORE it is too late to save data. When a drive indicates a SMART failure, it is trying to warn you that there is a very high probability of complete drive failure in the very near future. The drive may or may not be fully operational at this moment, but even more catastrophic failure is very possible very soon. If there is any important data on the drive, you should attempt to relocate it as soon as possible. OK, thanks for the detailed response, I really appreciate it. Since this is a brand new drive and is already in pre-fail, I will return it for a new one.

I just received two Seagate ST2000DL003 2TB drives from Amazon. I have run two preclear cycles. One has passed both preclear cycles with no SMART failures; One has failed on both preclear cycles with a SMART seek_error_rate failure. Raw_Read_Error_Rate looks very high as well. The drive that "passed" also had high values for these parameters although not nearly as high as these. Of five drives I have precleared, this is the only one to show a failure and I have never seen a failure in any desktop drive so I am not sure how reliable the SMART reports are. What say ye; should I return this to Amazon? I assume this is a legitimate indication of a bad drive as the seek_error_rate values seems incredibly high. Here is the SMART report generated at the end of the preclear with some information redacted: SMART status Info for /dev/sdc smartctl 5.40 2010-10-16 r3189 [i486-slackware-linux-gnu] (local build) Copyright © 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net === START OF INFORMATION SECTION === Device Model: ST2000DL003-9VT166 Serial Number: 5YD6HZP5 Firmware Version: CC3C User Capacity: 2,000,398,934,016 bytes Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 8 ATA Standard is: ATA-8-ACS revision 4 Local Time is: Sun Jan 1 11:39:35 2012 MST SMART support is: Available - device has SMART capability. SMART support is: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: FAILED! Drive failure expected in less than 24 hours. SAVE ALL DATA. See vendor-specific Attribute list for failed Attributes. General SMART Values: Offline data collection status: (0x82) Offline data collection activity was completed without error. Auto Offline Data Collection: Enabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 623) seconds. Offline data collection capabilities: (0x7b) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. Offline surface scan supported. Self-test supported. Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 1) minutes. Extended self-test routine recommended polling time: ( 255) minutes. Conveyance self-test routine recommended polling time: ( 2) minutes. SCT capabilities: (0x30b7) SCT Status supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 10 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 1 Raw_Read_Error_Rate 0x000f 116 100 006 Pre-fail Always - 105386328 3 Spin_Up_Time 0x0003 092 092 000 Pre-fail Always - 0 4 Start_Stop_Count 0x0032 100 100 020 Old_age Always - 9 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0 7 Seek_Error_Rate 0x000f 028 026 030 Pre-fail Always FAILING_NOW 13464724458629 9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 38 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0 12 Power_Cycle_Count 0x0032 100 100 020 Old_age Always - 9 183 Runtime_Bad_Block 0x0032 100 100 000 Old_age Always - 0 184 End-to-End_Error 0x0032 100 100 099 Old_age Always - 0 187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0 188 Command_Timeout 0x0032 100 100 000 Old_age Always - 0 189 High_Fly_Writes 0x003a 100 100 000 Old_age Always - 0 190 Airflow_Temperature_Cel 0x0022 068 065 045 Old_age Always - 32 (Min/Max 28/35) 191 G-Sense_Error_Rate 0x0032 100 100 000 Old_age Always - 0 192 Power-Off_Retract_Count 0x0032 100 100 000 Old_age Always - 7 193 Load_Cycle_Count 0x0032 100 100 000 Old_age Always - 9 194 Temperature_Celsius 0x0022 032 040 000 Old_age Always - 32 (0 22 0 0) 195 Hardware_ECC_Recovered 0x001a 037 024 000 Old_age Always - 105386328 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always - 0 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline - 0 199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Always - 1 240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offline - 66468913872934 241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offline - 2469991065 242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offline - 4264727547