TechFireSide

I'm running with :test and it just finished a backup with a new client I added. Seems to be in working order. One note, on default the storage is set to C:\ instead of /media...I have no idea if you are able to change that as a default for the container but for those that aren't as familiar with linux it might help to have that setup as default.

Seems to be working with that last update! I'll run some backups and let you know how it turns out. Thank you @binhex!

Different error this time after appending :test and doing an update. 2019-08-02 13:10:16,213 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23375073562296 for <Subprocess at 23375073562408 with name urbackup in state STARTING> (stdout)> 2019-08-02 13:10:16,213 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 23375073656112 for <Subprocess at 23375073562408 with name urbackup in state STARTING> (stderr)> 2019-08-02 13:10:16,213 INFO exited: urbackup (exit status 127; not expected) 2019-08-02 13:10:16,214 DEBG received SIGCHLD indicating a child quit 2019-08-02 13:10:19,218 INFO spawned: 'urbackup' with pid 72 2019-08-02 13:10:19,230 DEBG 'urbackup' stderr output: /usr/bin/urbackupsrv: error while loading shared libraries: libcryptopp.so.7: cannot open shared object file: No such file or directory

I enabled privileged mode (I am running btrfs on my cache) on the container and it didn't help. I also removed the container and image, cleared the appdata folder and re-deployed the container just to troubleshoot but it's still not working. Same errors as before. I saw the CPU comments. In case it matters I am running old Intel processors. 2x X5690 Xeons.

Just tried to install this today and seems like I'm getting the same errors as others. I run about 10 other containers with no issues on 6.7.2 so if it's this sqlite bug it's only affecting this container. 2019-08-01 11:27:22,525 DEBG fd 8 closed, stopped monitoring <POutputDispatcher at 23427983346600 for <Subprocess at 23427983438008 with name urbackup in state STARTING> (stdout)> 2019-08-01 11:27:22,525 DEBG fd 10 closed, stopped monitoring <POutputDispatcher at 23427983441256 for <Subprocess at 23427983438008 with name urbackup in state STARTING> (stderr)> 2019-08-01 11:27:22,525 INFO exited: urbackup (exit status 132; not expected) 2019-08-01 11:27:22,526 DEBG received SIGCHLD indicating a child quit 2019-08-01 11:27:25,530 INFO spawned: 'urbackup' with pid 60 2019-08-01 11:27:25,554 DEBG 'urbackup' stderr output: /home/nobody/start.sh: line 15: 65 Illegal instruction /usr/bin/urbackupsrv run --config /config/urbackup/config/urbackupsrv --no-consoletime I'd be happy to post more info if that will help troubleshoot the issue. P.S. Thank you for the work you put into these projects @binhex I actually just got done converting all of my other containers to yours today (I love your delugevpn container so it made sense to convert my radarr and sonarr to yours) and found this new urbackup container while I was doing that

I just tried reinstalling it from community applications to get this for you (I had already deleted the non-working container) and it went straight to the Email prompt (aka working!). Not sure if you fixed something or if something changed on my system with me installing the docker container from "scratch" but the community applications version seems to be working for me now. Thank you for the quick responses! The unraid community applications community is one of the primary reasons I went with unraid and so far I haven't been disappointed

If you look at the logs (just that button to the right of the container Title/Icon) is it showing something about trying to start the crashplan engine over and over again? This sounds a lot like what was happening to me is why I ask.

Yeah so it was a clean install using community applications. I left everything default except for the locations of flash and my storage and adjusting the max ram it could use. When it didn't boot the first time (would load web interface but said it couldn't connect to crashplan service/engine) I looked at the logs and saw that it just kept trying to start the crashplan engine over and over again (80% of the log was full of attempts). I removed the max ram setting thinking maybe that was throwing it off but it still had the same behavior. I tried deleting the container and installing it again through community applications (after cleaning our the old appdata settings folder) and it still had the same behavior. The only thing that got crashplan-pro working for me was to download the docker container directly from docker and setting up the variable and storage locations myself. It should be the exact same docker container so I'm really confused why the community applications "version" isn't working.

Just a preface I'm new to unraid but have moderate experience with docker and linux. So I've used these app templates for most docker containers and they've been awesome but for some reason this template for crashplan-pro isn't working for me. It gets stuck starting the crashplan engine over and over again. I installed the plain docker container for the same crashplan-pro image and setup the variables etc myself and it seems to work perfectly so I can only assume something in this template must be causing this issue. Any idea of what this could be or how I could help troubleshoot this?