stchas

That fixed my issue. Thanks SimonF!

I managed to kludge the XML for my Win10 VM such that it takes out the /boot drive when it starts, wreaking havoc on the system. Unfortunately, the Autostart switch for the VM was set when I was editing the XML, so restarting unraid puts me into the same bad situation. To avoid this do-loop, I manually disabled the VM Manager in the /boot/config/domain.cnf file and rebooted the system. Now works fine (without VMs). However, re-enabling the VM Manager in Settings starts the same sequence of events, as re-enabling the VM Manager also re-starts any VMs with the Autostart switch set. So no way to get into the VM XML editor to fix the problem. So I need a way to clear the Autostart switch for the VM from outside the VM Manager. Any help is greatly appreciated!

Reloaded the Docker image and that did the trick! Thanks!

I received a message from CrashPlan that it has been unable to back up for 3-1/2 days. History log looks like: Does the CrashPlan docker need to be upgraded to fix this problem?

If I delete a sub-folder and then "undelete" it by copying or moving it back to the original folder from the user share's .Recycle.Bin, the next day it shows up again in the user share's .Recycle.Bin and is removed from the original folder. Any suggestions? Running unRAID 6.6.7, RecycleBin 2019.03.08b, Windows 10. In this example, I deleted the 2018 and 2019 Income Tax sub-folders from the Income Tax Files folder on the Records share. Later, I copied them back from the .Recycle.Bin to the Income Tax Files folder on the Records share. The next day, they showed up again in the .Recycle.Bin and were removed from the Income Tax Files folder.

I'm using Norton Security with no issues.

Check to make sure your CrashPlan "Inbound backup from other computers" folder is set to /backup. You can set this location in CrashPlan under Settings, General tab. I believe the default folder is /data, which will be in the docker image.

Thanks for the suggestions Squid. I believe I have tracked the issue down to Dropbox throwing error messages that it wasn't assigned to a user account after I re-created the docker during the unRAID 6.1.9->6.2 transition. There must be a logfile internal to the Dropbox docker that was filling up the docker.img space. All is quiet now

I'm having a similar problem. I installed unRAID 6.2 about three weeks ago. Deleted/regenerated my 20GB docker.img and reloaded all the docker containers from my "My-xxxxxx" user defined templates. Over the intervening weeks I've been receiving notification messages that my docker file utilization is slowly increasing, now up from 70% to 91%. I have double-checked the folder mapping for all of the installed dockers and confirmed they are pointing outside the docker image. Is there a systematic way I can go about periodically logging the disk space usage for each docker to identify which one is growing?

This pull running SABnzbd version 1.1.0RC4. Enable MultiCore Par2 is greyed out and unchecked.

I have Win7 on a dedicated, bootable drive in my dual-boot test server that works fine alongside an unRAID array. As others have noted, you have to make sure Windows doesn't access any of the unRAID array drives when it's running. The other challenge for you specifically (with a headless system) is that you have to be able to access the motherboard BIOS to tell it which OS to boot into (i.e., boot unRAID from flash drive, boot Windows from Win7 drive). As others have also noted, using a VM for your other "full blown Server OS" may be a better solution, as it allows unRAID and your Server VM to run side-by-side, and eliminates the need to access the BIOS. That's what I do on my production server, where I have Win10 running in a VM.

Arrow keys and DEL and Backspace keys don't work since last update.

For a Windows VM, for example, I want to make sure Windows shuts down to force it to flush any volatile memory and disk buffers to the vdisk prior to making the backup.

I was not able to get the script to run successfully because of a couple of things specific to my setup, one being the name of my VM has spaces in it, and the other that I had my VM shutdown prior to running the script. Here's the play-by-play: root@Tower:/boot/custom/bin# backup_unraid_vms.sh starting backup_unraid_vms.sh to backup Win7 Virtual Desktop to /mnt/user/System/Win7-VM starting backup of Win7 checking /mnt/user/System/Win7-VM/Win7 exists so i have somewhere to put the backup files /mnt/user/System/Win7-VM/Win7 doesnt exist so i am going to create it /mnt/user/System/Win7-VM/Win7 has been created backup of Win7 failed completed backup_unraid_vms.sh to backup Win7 Virtual Desktop to /mnt/user/System/Win7-VM starting backup of Virtual checking /mnt/user/System/Win7-VM/Virtual exists so i have somewhere to put the backup files /mnt/user/System/Win7-VM/Virtual doesnt exist so i am going to create it /mnt/user/System/Win7-VM/Virtual has been created backup of Virtual failed completed backup_unraid_vms.sh to backup Win7 Virtual Desktop to /mnt/user/System/Win7-VM starting backup of Desktop checking /mnt/user/System/Win7-VM/Desktop exists so i have somewhere to put the backup files /mnt/user/System/Win7-VM/Desktop doesnt exist so i am going to create it /mnt/user/System/Win7-VM/Desktop has been created backup of Desktop failed completed backup_unraid_vms.sh to backup Win7 Virtual Desktop to /mnt/user/System/Win7-VM Things to fix: 1. It needs to handle VM names with embedded spaces. My VM's name is "Win7 Virtual Desktop." When the script parses vms_to_backup="Win7 Virtual Desktop," it identifies VMs with names "Win7," "Virtual," and "Desktop" and creates subfolders for those backup vdisks. 2. It needs to trap invalid VM names (already on your list), such as what occurred in item 1 above (e.g., "Win7" is not a valid VM name). 3. I was not able to confirm, but I don't think it will back up vdisks for VMs that are already shutdown when the script starts. When you define the vm_state variable, use "virsh list --all" instead of "virsh list." Then add a state check for VM already shutdown. For this condition, you'll have to decide whether to restart the VM (my vote would be "no"). if [ "$vm_state" == "$vm shut off" ]; then echo "$vm is already in shutdown state" can_backup_vm="y" fi I really appreciate the work you've done putting this script together. I expect it will get a lot of use as people discover how easy it is to use and how effectively it fills the need for backing up VMs.

Thanks, danioj. I'll test over the weekend.

Thanks, guys! Just what I was looking for.

Is there a way to shut down / restart a [Win7] VM with a script like you can a docker container? That would allow us to back up the vdisk using cron. I use Acronis, too, but I'm a belts-and-suspenders guy like danioj.

I'm using a single 250GB SSD for cache, docker apps, and a Win7 VM. Seems to work just fine.

Installed Preclear Plugin this weekend and really like it. Much easier (and safer) to use than the command line version. While preclearing a Seagate 3TB NAS drive, I noted that the Start Preclear popup incorrectly displays the drive information (see attachment), where the serial number shows up in the Device Model field, the firmware version in the Serial Number field, and the size in the Firmware Version field. Firefox 44.0.2 is the browser.

Got one

For consistency with the other disk settings pages, it would be nice to have a Comments field where we can store notes for the parity disk. Also, probably don't need a Spinup Group(s) field for the parity disk.

I'm not able to edit the per disk settings for disk utilization or temperature thresholds (greyed out). Tried with array on-line and off-line. I am able to edit the global settings on the Disk Settings page. Using Firefox 43.0.4.

I'd like a hook in the docker manager that will support automatically running a script after a docker container starts. Here's a couple of examples of what I'd like to do after the CrashPlan docker starts: [*]change the permissions on appdata/crashplan/conf/service.model to 0666 (changed to 0600 in CP rev 4.5, creates SyncBack error) [*]create a revised appdata/crashplan/id/.ui_info with the unRAID server IP address substituted for 0.0.0.0 (broken in CP circa rev 4.1?) Having a generic feature in the docker manager to run a user script upon starting will give us the ability to implement work-arounds for undesired behaviors of the underlying apps, such as the issues we're having with CrashPlan. Right now we have to do some manual gyrations to keep CrashPlan running, and every update seems to bring new challenges (see here and here and here).

The two items I'm working on are work-arounds for changes Code42 implemented in recent revisions of CrashPlan. They have not been particularly responsive to requests for relief. You know the drill: "... running the CrashPlan service on a headless computer is an unsupported feature..." and "... security decision made by our engineers that we have no intention of reversing." No, this is a gfjardim container Right; wasn't quite ready to take that step. I was really hoping there was a generic hook in the docker manager that would facilitate user scripts that I didn't know about. I can't believe I'm the only one that might see a use for this feature. Thanks for the ideas, guys!

I'd like to be able to automatically run a script after a docker container starts. How might I do that? Couple of examples of what I'd like to do: [*]change the permissions on appdata/crashplan/conf/service.model to 0666 (changed to 0600 in CP rev 4.5, creates SyncBack error) [*]create a revised appdata/crashplan/id/.ui_info with the unRAID server IP address substituted for 0.0.0.0 (broken in CP circa rev 4.1?) I don't need help creating the script(s); what I need help on is figuring out how to have the docker manager run the script(s) automatically when the container is started. Thanks in advance for your help!