May 19, 20242 yr On 5/18/2024 at 2:30 AM, egtrev said: Yes, the bottom of your screen is being cut off. I see Done and Restore Files at the bottom. My Display Width and Height are 1280 and 1024. You do need a writable location to restore to. I created a /RESTORES location that is mounted R/W and points to a normally empty folder rather than making the entire user share writable. Edited May 19, 20242 yr by icepic0
May 19, 20242 yr 5 hours ago, icepic0 said: My height looks to have been set to 840, I made it 1024 and I can see the Restore button now. Thanks for the help.
June 5, 20242 yr Howdy @Djoss I just wanted to let you know that the Crashplan WebGui is indicating "CrashPlan wasn't able to upgrade but will reattempt in one hour" Checking for updates on Unraid's Docker Container tab indicates this is up to date. As always, thank you greatly for maintaining this wonderful container.
June 5, 20242 yr Author 8 minutes ago, landS said: Howdy @Djoss I just wanted to let you know that the Crashplan WebGui is indicating "CrashPlan wasn't able to upgrade but will reattempt in one hour" Checking for updates on Unraid's Docker Container tab indicates this is up to date. As always, thank you greatly for maintaining this wonderful container. Yes, I'm working on this !
June 14, 20242 yr Is anyone else having an issue where their Crashplan is stuck on "Waiting for connection"?
June 16, 20242 yr Looking at mine now and it's back to "Backup running". Whatever the issue was seems to be resolved now.
June 16, 20242 yr It's working again for me as well. I also found the CrashPlan status page. Looks like they've had an issue for over a week. https://status.crashplan.com/
August 10, 20241 yr After upgrading to the latest version of this container a few weeks ago, I'm unable to login to the gui. There is nothing special about the way I've configured this container, it's configured in bridge mode, and it's been working stably for almost two years. I'm on unraid 6.12.10, docker engine configured for macvlan network type. Suffice it to say, I can login to the CrashPlan website with the same set of credentials, and before upgrading never experienced an issue logging in through the docker app UI. I do have 2FA enabled, which I noted is now part of the login pop-up for the GUI, which was absent in previous versions of this docker app; I also have a particularly long password, and I'm wondering if there's perhaps a length limitation in the GUI that didn't previously exist? I've scoured the service.log.0 file, and there is nothing in the log I can locate that time-correlates with this login failure. Login error pop-up attached.
August 12, 20241 yr Author On 8/10/2024 at 9:25 AM, NDDan said: After upgrading to the latest version of this container a few weeks ago, I'm unable to login to the gui. There is nothing special about the way I've configured this container, it's configured in bridge mode, and it's been working stably for almost two years. I'm on unraid 6.12.10, docker engine configured for macvlan network type. Suffice it to say, I can login to the CrashPlan website with the same set of credentials, and before upgrading never experienced an issue logging in through the docker app UI. I do have 2FA enabled, which I noted is now part of the login pop-up for the GUI, which was absent in previous versions of this docker app; I also have a particularly long password, and I'm wondering if there's perhaps a length limitation in the GUI that didn't previously exist? I've scoured the service.log.0 file, and there is nothing in the log I can locate that time-correlates with this login failure. Login error pop-up attached. Note that you can copy the displayed URL and paste it in your browser to do the login yourself. If you would like to provide more details about the failure, you can edit the container setting and add a new variable named "CONTAINER_DEBUG", with a value of "1". You can then reproduce the problem and get the file /tmp/cp_login.log inside the container. You can send me its content in a private message.
August 13, 20241 yr 22 hours ago, Djoss said: Note that you can copy the displayed URL and paste it in your browser to do the login yourself. If you would like to provide more details about the failure, you can edit the container setting and add a new variable named "CONTAINER_DEBUG", with a value of "1". You can then reproduce the problem and get the file /tmp/cp_login.log inside the container. You can send me its content in a private message. Copying and pasting the session URL into another browser to complete the login, worked perfectly, that's what I'll roll with. Thanks @DJoss!
October 19, 20241 yr Hi, I'm trying to login but I always get the "Unable to sign-in" error message. I added the environment variable CRASHPLAN_SERVER_ADDRESS: SMB and checked from inside the container: /tmp # printenv ......... CRASHPLAN_SERVER_ADDRESS=SMB .......... What else could I do? Thanks.
October 21, 20241 yr Author On 10/19/2024 at 6:32 AM, giorizzotti said: Hi, I'm trying to login but I always get the "Unable to sign-in" error message. I added the environment variable CRASHPLAN_SERVER_ADDRESS: SMB and checked from inside the container: /tmp # printenv ......... CRASHPLAN_SERVER_ADDRESS=SMB .......... What else could I do? Thanks. This variable is no longer needed. Can you share a screenshot of the error you are getting ?
October 22, 20241 yr On 10/21/2024 at 2:21 AM, Djoss said: This variable is no longer needed. Can you share a screenshot of the error you are getting ? It was due to some special character in my account password. I changed the password and was able to login. Thank you!
October 22, 20241 yr Anybody else’s upload speed gone to shit after the latest update? I’m not seeing any errors in logs anywhere, but the speeds reported have dropped to the low kbps range. I removed the speed cap in settings just in case, checked my actual internet connection, checked the Ethernet connection, and I see no issues. I rebooted the server as well and waiting to see if that does anything, but I’m not hopeful. I feel like I’m on the worst dial-up connection ever.
October 22, 20241 yr 2 hours ago, acurcione said: Anybody else’s upload speed gone to shit after the latest update? I’m not seeing any errors in logs anywhere, but the speeds reported have dropped to the low kbps range. I removed the speed cap in settings just in case, checked my actual internet connection, checked the Ethernet connection, and I see no issues. I rebooted the server as well and waiting to see if that does anything, but I’m not hopeful. I feel like I’m on the worst dial-up connection ever. Yes -- 100%, I'm averaging 800kb/s, the upgrade, while not the definitive root cause, was a correlating event to the massive speed drop. Edited October 22, 20241 yr by NDDan
October 22, 20241 yr 1 hour ago, NDDan said: Yes -- 100%, I'm averaging 800kb/s, the upgrade, while not the definitive root cause, was a correlating event to the massive speed drop. Everything I see in my logs supports this, but I have no clue how to fix it. Is there something new or a change in the container that could be the cause? A setting or something? This is freaking painful.
October 26, 20241 yr There appears to be something in the new build of CrashPlan that is causing this. I reverted back to build 24.08.1 yesterday and my speeds were back to normal overnight. If you haven't done so, and you still are having the same issue, I think you could reasonably correlate that it wasn't 'fixed' miraculously overnight, but that it might be build-related. I recommend you target this repo and test: Quote jlesage/crashplan-pro:v24.08.1 @Djoss any thoughts on this? I looked at the commit, and the changes are just the base distro v4.6.3->v4.6.4 and CrashPlan 11.4.0->11.4.1. I checked the app.log and the same endpoint is being targeted, I don't see any config differences listed either. Not sure what to make of this, but for the time being, I've reverted builds, and I'm back in business.
October 26, 20241 yr 33 minutes ago, NDDan said: There appears to be something in the new build of CrashPlan that is causing this. I reverted back to build 24.08.1 yesterday and my speeds were back to normal overnight. If you haven't done so, and you still are having the same issue, I think you could reasonably correlate that it wasn't 'fixed' miraculously overnight, but that it might be build-related. I recommend you target this repo and test: @Djoss any thoughts on this? I looked at the commit, and the changes are just the base distro v4.6.3->v4.6.4 and CrashPlan 11.4.0->11.4.1. I checked the app.log and the same endpoint is being targeted, I don't see any config differences listed either. Not sure what to make of this, but for the time being, I've reverted builds, and I'm back in business. Thanks for that. Trying now. I wasn’t sure how to revert to an earlier build. 😀
October 27, 20241 yr That did the trick. Upload time went from 89 days to 15 hours. I’d say there’s a definite issue in that build somewhere.
October 29, 20241 yr I have not; I figured running this as a container would be outside their support terms.
November 21, 20241 yr On 1/25/2024 at 10:24 PM, jonspieg said: Suddenly my crashplan docker refuses to start properly. It initially seems to start but after a short while it's marked as stopped. It happened once before with no apparent cause, but upgrading unraid to the latest version solved the issue, until it suddenly happened again. restarting the server doesn't help. Any help will be much appreciated! Here's the log: ╭――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╮ │ │ │ Application: CrashPlan for Small Business │ │ Application Version: 11.1.1 │ │ Docker Image Version: 23.06.2 │ │ Docker Image Platform: linux/amd64 │ │ │ ╰――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――――╯ [cont-init ] 89-info.sh: terminated successfully. [cont-init ] all container initialization scripts executed. [init ] giving control to process supervisor. [supervisor ] loading services... [supervisor ] loading service 'default'... [supervisor ] loading service 'app'... [supervisor ] loading service 'gui'... [supervisor ] loading service 'certsmonitor'... [supervisor ] service 'certsmonitor' is disabled. [supervisor ] loading service 'nginx'... [supervisor ] loading service 'xvnc'... [supervisor ] loading service 'openbox'... [supervisor ] loading service 'CrashPlanEngine'... [supervisor ] loading service 'logmonitor'... [supervisor ] loading service 'logrotate'... [supervisor ] all services loaded. [supervisor ] starting services... [supervisor ] starting service 'xvnc'... [xvnc ] Xvnc TigerVNC 1.13.1 - built May 16 2023 17:43:49 [xvnc ] Copyright (C) 1999-2022 TigerVNC Team and many others (see README.rst) [xvnc ] See https://www.tigervnc.org for information on TigerVNC. [xvnc ] Underlying X server release 12014000 [xvnc ] Thu Jan 11 21:24:25 2024 [xvnc ] vncext: VNC extension running! [xvnc ] vncext: Listening for VNC connections on /tmp/vnc.sock (mode 0660) [xvnc ] vncext: Listening for VNC connections on all interface(s), port 5900 [xvnc ] vncext: created VNC server for screen 0 [supervisor ] starting service 'nginx'... [nginx ] Listening for HTTP connections on port 5800. [supervisor ] starting service 'openbox'... [supervisor ] starting service 'CrashPlanEngine'... [supervisor ] starting service 'app'... [app ] Bus error [supervisor ] starting service 'logmonitor'... [logmonitor ] Monitoring log file: /config/log/service.log.0 [logmonitor ] Monitoring status file: /config/log/app.log [supervisor ] all services started. [supervisor ] service 'app' exited (with status 135). [supervisor ] service 'app' exited, shutting down... [supervisor ] stopping service 'logmonitor'... [supervisor ] service 'logmonitor' exited (got signal SIGTERM). [supervisor ] stopping service 'CrashPlanEngine'... [supervisor ] stopping service 'openbox'... [supervisor ] service 'openbox' exited (with status 0). [supervisor ] stopping service 'nginx'... [supervisor ] service 'nginx' exited (with status 0). [supervisor ] stopping service 'xvnc'... [xvnc ] Thu Jan 11 21:25:00 2024 [xvnc ] ComparingUpdateTracker: 0 pixels in / 0 pixels out [xvnc ] ComparingUpdateTracker: (1:-nan ratio) [supervisor ] service 'xvnc' exited (with status 0). [supervisor ] sending SIGTERM to all processes... [supervisor ] sending SIGKILL to all processes... [supervisor ] service 'CrashPlanEngine' exited (got signal SIGKILL). [finish ] executing container finish scripts... [finish ] all container finish scripts executed. I know it's been a while, but I'm having this exact problem right now. Do you remember how to fix this?
November 29, 20241 yr On 11/21/2024 at 10:53 AM, Cathnan said: I know it's been a while, but I'm having this exact problem right now. Do you remember how to fix this? In case anyone else stumbles over this with this problem, I wasn't able to outright solve it. But I got the container back up running using the docker compose plugin and copying all settings into the docker-compose file, as I set them in the unraid docker config. I also pointed to the exactly same appdata directory for the container config without changing anythin in it. Something must be quite messed up in my docker environment. Third container already that I had to switch over to docker-compose because it suddenly stopped working and I couldn't get it back up running. Even deleted the docker.img and rebuild everything to no avail.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.