dlandon

There have been quite a few changes to zmeventnotification.ini over the last few releases of zmeventnotification. You should review the default .ini file and make appropriate changes to your .ini file if you are not using the default .ini.

My guess is that your dockers are locking up when they lose access to the shares.

Yes. UD will eventually time out when the remote shares are not accessible. It depends on how many remote shares you have mounted. The issue with the Dockers hanging has nothing to do with UD. I can imagine they struggle a lot when the remote mounts go away. Show a screen shot of the UD webgui so I can see what you are mounting remotely. Why so much remote mounting? You are probably asking for problems like you have when your network goes off, or the remote server is rebooted. Why not move some of the data to the local server?

Be sure you have the latest version of UD installed. Your server should not lock up with remote shares going off line. UD is probably very busy trying to deal with the preclear status updates and your remote shares going offline. Remove the preclear plugin and try again. Post your diagnostics. You can get the diagnostics from the command line with 'diagnostics'.

I appreciate what it is that you are looking for and can understand your frustration. This plugin is offered to help recover deleted files. As you may have seen, the file versions are noted by a copy number. It would be nice to have a recover button to restore the file back to it's original location, but that would take a major effort in creating a file browser with that capability. I volunteer my efforts and do not get paid for my time. It's not an undertaking I am interested in investing in for the few times it would be used. While it is a bit cumbersome to have to download the file and copy it to the restored location, this is not an everyday operation.

Thought I had all this worked out. Fixed in the next release.

You didn't read the first post. Start over. This is the setup for your configuration. This is the initial login setup.

Here you go. #!/bin/bash # # Backup MyComputer desktop VM. # TIMEOUT=${TIMEOUT:-300} # # Stop the VM. # echo "Shutdown MyComputer VM" virsh shutdown MyComputer echo "Waiting for MyComputer VM to shutdown..." count=0 while [ $(/usr/sbin/virsh list --name --state-running | grep "MyComputer" | wc -l) -gt "0" ]; do if [ "$count" -ge "$TIMEOUT" ]; then break fi count=$(expr $count + 1) sleep 1 done if [ $(/usr/sbin/virsh list --name --state-running | grep "MyComputer" | wc -l) -gt "0" ]; then echo "MyComputerVM did not shut down" /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "VM Backup" -d "MyComputer VM Backup failed" -i "normal" exit 1 else echo "MyComputerVM successfully shut down" fi # # Copy VM to array Computer Backups # echo "Copy MyComputerVM to array..." rsync -a -v --delete /mnt/user/system/domains/MyComputer /mnt/user/Computer\ Backups/VM_BACKUPS/ # # Start the VM. # echo "Start MyComputer VM..." virsh start MyComputer /usr/local/emhttp/webGui/scripts/notify -e "Unraid Server Notice" -s "VM Backup" -d "MyComputer VM Backup completed" -i "normal" echo "MyComputerVM Backup Done" It shuts down the VM normally and waits a certain amount of time to be sure it has stopped, backs up the VM to the array and then restarts the VM. This performs a full shutdown of the VM and not a hibernate. Change 'MyComputer' to the name of your VM. You'll have to adjust the rsync destination to your NFS share. Over the network, a sizable VM could take a while.

My advice is to put the ownCloud /config on an SSD cache share. Just putting the /data on disk 1 probably won't accomplish what you want depending on the activity on ownCloud. Any /data file activity would spin up the disk. i.e. uploading, downloading, or viewing files. Put the ownCloud /config on a SSD cache, and back it up regularly to the array. ownCloud has a plugin in the marketplace that does a database backup regularly, and you can safely copy the /data folder to the array with a User Script, even with ownCloud running. You will also find that ownCloud will be more responsive on a SSD share.

Are you having any other issues with other shares or files not purging out the aged files? Run this command and see if there are any errors. /usr/local/emhttp/plugins/recycle.bin/scripts/rc.recycle.bin purge I wouldn't expect to see any errors. The other thing you can check are the dates of the files. Some time ago the aging determination was changed and these files might have an issue with the dates. 2017.05.07 Add: Changed the recycle bin aging to the last access date and don't change the modify date when the file is put in the recycle bin.

From what I can see, your shares are all on disk1. You're mapping directly to the disk and not the share. Don't do that, even if you have shared the disk1. Do it this way. Create a share called 'owncloud'. Set it to use disk1 only. Then map the config folder of ownCloud to '/mnt/user/owncloud'. The /data folder will then be in this share and all of the /config will be located in the 'owncloud' share on disk1. Always refer to shares by the mount point '/mnt/user/share'. Never map to disks directly. You will create problems!

If I recall, that type is because the drive was part of a raid system and can't be mounted by UD.

Look at the log. It will tell you why it won’t mount.

Post your diagnostics. I think your issue might be the way you've set up your shares.

As far as I know these have been addressed. There was a change in the default timeout on a CIFS mount that was shortened from the original default of 120 seconds. I adjusted the mount timeout to 120 seconds and that should have taken care of the timeout messages in the log. If anyone is having issues, please post a diagnostics so I can have a look.