jademonkee
-
Posts
333 -
Joined
-
Last visited
Content Type
Profiles
Forums
Downloads
Store
Gallery
Bug Reports
Documentation
Landing
Posts posted by jademonkee
-
-
51 minutes ago, jowi said:
What i did was set the version manually (i forgot what version exactly) update it, and then set it to 'latest', and get the lastest version. After that, it was working again. As i understand it, that was the fix: 1. update to version x manually, 2: update that to the latest.
So, how can i see what the version is i have actually installed?
*edit* if i check version in mariadb itself it says : 10.5.12-MariaDB
Don't know if the docker version is something else?
You can see the available tags here:
https://hub.docker.com/r/linuxserver/mariadb/tags?page=1&ordering=last_updated
I don't know the difference between version-10.5.12-r0 and 10.5.12-r0-ls36 but maybe someone here can advise. If you swap to one of those versions, you'll stay on that version until you change the tag. (I think you may still get minor updates to the container, but not mariadb - someone will have to confirm).
In saying that, it seems that "latest" would be one of those two, so it's probably no problem updating this time as the latest image is still some variant of the 10.5.12 version you're on (or even the exact same version), and - again - the problems were because of the 'rebasing' of the image, not an update to mariadb itself. So yeah. It's probably pretty safe to update - but there's also no harm in waiting for a few more people in the thread to speak of their experience.
-
1
-
-
27 minutes ago, jowi said:
But i did the fix, and now there is an update... so it won't let me skip this update. I have to manually do ALL other updates, otherwise if i ' update all' this will update as well...
i will wait for confirmation from others that did the fix and applied this latest update.
Sorry, it seems you misunderstood: Step 1 of the fix was to set the tag to a manual version, step 2 was to specify the 'latest' tag, which will always pull down the latest version.
If you set the tag to the version you're currently on, it will stay on that version. Any Docker updates will just be to the related container files, not mariadb itself, so shouldn't break anything.
In saying that, I have the latest update and it's fine.
However, I didn't have a problem when I upgraded to the Alpine base (although it was suggested earlier in this thread that the errors happened only on larger DBs, as they took longer to shut down than was given by the "update" command. The tag swap 'fix' worked because it did a "shutdown" command before upgrading, which gave mariadb enough time to shut down gracefully before the update, so it gave the impression of it doing more than it really did).
-
2 hours ago, jowi said:
Unraid tells me there is an update for the mariadb docker, but i'm affraid to install it, since last time everything went wrong.
How do i know this update will be ok? Someone tried it?
Is there a way to know to what version it will be updated? Is there a way to rollback?
Is there a way to exclude a docker from updates? At the moment, i can not update all, since i dont want mariadb to update, so i have to update all others manually one by one...
You can manually specify a version for mariadb to stay on, and it will stay on it (that's what the 'fix' earlier in this thread involved).
However, the reason that things broke last update was because it moved to an Alpine base from Ubuntu. That won't happen again, so future updates should be fine (and may come with security benefits).
-
Anyone here have any idea how to get this container to support AAC / M4A files?
I added some to my library, but they don't even appear in the library after a scan, let alone allow me to play them. Any idea how to get them working?
I don't know how to access the files mentioned here: https://wiki.slimdevices.com/index.php/AAC.html
And don't know if FAAD2 is installed or not (nor how to install it).
Thanks all!
-
FYI Customer Support have said that my maintenance has now completed and it's now ok for me to log back in again, so I have done so. Will see if the sync finishes and report back if it does/doesn't.
Here's the email as it contains some good info:
QuoteYour device is now out of maintenance so you may feel free to sign back into the CrashPlan app.
Give CrashPlan some time to rebuild your cache, re-scan your hard drive(s), then see if it is able to connect and resume backing up. It will spend a fair amount of time analyzing block data and resynchronizing with the server, but should resume backing up when it is done.
It will appear your backup is starting over, but as it gets to files already backed up they will be skipped. Since CrashPlan backs up newer and smaller files first, it often takes running for some time until CrashPlan is convincingly doing this, so just keep letting it run.
More info:
* Sign out of the Code42 app: https://support.code42.com/CrashPlan/6/Configuring/Sign_out_of_the_Code42_appIf, after ~24hrs, behavior does not seem to have improved, please reply and we will be happy to assist further.
Please let me know if you have any further questions.
-
I updated this morning and have this in the logs:
QuoteUser uid: 99
User gid: 100
-------------------------------------
[cont-init.d] 10-adduser: exited 0.
[cont-init.d] 30-config: executing...
[cont-init.d] 30-config: exited 0.
[cont-init.d] 40-initialise-db: executing...
[cont-init.d] 40-initialise-db: exited 0.
[cont-init.d] 90-custom-folders: executing...
[cont-init.d] 90-custom-folders: exited 0.
[cont-init.d] 99-custom-files: executing...
[custom-init] no custom files found exiting...
[cont-init.d] 99-custom-files: exited 0.
[cont-init.d] done.
[services.d] starting services
[services.d] done.
210826 10:05:52 mysqld_safe Logging to '/config/databases/98571c4a56a9.err'.
210826 10:05:52 mysqld_safe Starting mariadbd daemon with databases from /config/databasesIt's not adding any extra lines (like, they're not repeating), and Swag + NextCloud are working fine (the only things that use it - and I don't even remeber if they both do, or just NC... heh)). Is that safe mode anything to worry about? Or is it all good?
-
14 hours ago, snowboardjoe said:
Just tried that and logged back in. Monitoring.
The customer support agent that suggested I deauthorize told me not to log back in until they told me to. It's because there is some maintenance occuring on the data stored on their servers, and the file sync can sometimes interfere with that. So the deauthorization stops the file sync so that the maintenance can complete without interruption. By logging back in immediately, the maintenance doesn't have a chance to complete.
So I'm waiting for the customer support agent to tell me when it's ok to log back in.
-
13 hours ago, snowboardjoe said:
This is unacceptable.
Yeah, I'm sick of these periods of syncing an no-backups.
I've been considering buying an old HP Microserver and installing it in a closet at a friend's place to run a weekly rsync backup to. However, with CrashPlan only $12/month, it'll take a little too long to pay off... so I keep giving up on the idea.
-
I've just received the following from CrashPlan support:
QuoteThe reason for this behavior is due to the sync and maintenance conflicting on priority.
Archive maintenance is a regularly scheduled task that runs on each backup destination. The purpose is to maintain archive integrity and optimize the size of the archives. Maintenance may take several days to run. Typically maintenance is able to complete and backups resume correctly afterward, however if the activities are both disrupting each other we won't see good progress.
Please deauthorize the CrashPlan application. With the CrashPlan desktop application, double click the Code42 icon in the top left of the application (above your device name) to open the Code42/CrashPlan Command Line Interface.
Alternatively: Press Shift + Control + C (Option + Command + C on Mac)
You may then type the following command:
deauthorize
and press enter to run it. This command will cause the CrashPlan application to close.
Please don't sign back in yet. I will monitor the progress of maintenance and let you know when to sign back in.
I'll report back on any progress.
-
1
-
-
12 minutes ago, Djoss said:
CrashPlan has been updated recently. This triggers a synchronization. Is it what you are seeing ?
I'm seeing a synchronization, yes. However, it's been however many days now and it's never hit 100%. It keeps climbing then dropping back to 0%, just as it did in my earlier posts. I've reached out to CrashPlan support to see if they can shed any light on it.
-
FYI I decided to upgrade to v6.2.26 using the docker tag:
linuxserver/unifi-controller:version-6.2.26
I also updated the firmware of my two AP AC LR to v5.43.38 (from v4), although one of them kept failing, and I had to 'cache' it in the controller before the upgrade worked successfully (Settings > Maintenance > Cache). The other (slightly newer hardware) updated fine the first time (before I'd cached the firmware), however.
I also had to change my guest network authentication to explicitly use a password, and then re-enter what used to be the "WPA2" password (I don't use a portal, it's just an isolated network I use for untrusted devices).
I also changed the Internet > WAN > Advanced > DHCP to point to my pihole DHCP server (don't know if I had to, but there was no value in that box) as well as Network > LAN > Advanced > DHCP UniFi Controller to point to my pihole DHCP sever, too, just in case that was needed as well.
Aside from the firmware update hiccup, everything seems to be working well. I can't really see anything missing from the 'new' interface, and am enjoying its layout. I am generally a 'set and forget' user, though, so power users may find the new interface lacking.I'll report back if anything breaks.
Thanks for taking the initial plunge @PeteAsking!
-
1
-
-
On 6/18/2021 at 10:49 AM, jademonkee said:
Just popping in to say that 30 days later I FINALLY have backups completed again.
Thanks again, everyone, for your help.
Well, not anymore. I'm having the same problem of 'synchronizing file information' endlessly looping.
I'm about ready to chuck in the towel with crashplan and just install another Unraid box at a friend's house and run an rsync once a week.
-
13 hours ago, PeteAsking said:
I have updated to version-6.2.26 today just fyi.
Let us know what you think of it in a couple weeks. I still haven't taken the plunge, although it seems like most of the big problems were sorted in this latest release.
-
55 minutes ago, allroy1975 said:
hey @jademonkee did you have to DO anything? I feel like i'm having a real similar issue. I had some system problems around the beginning of the month and now that i'm stable again, I keep seeing "Synchronizing block information" but it climbs to 100% then just starts over. It looks like i changed the memory in the RIGHT place 😉 a few days ago to 3072 from 2048 which had been working fine.
or did you just let it sit and after a LONG time it finally got itself all synced up and is working correctly?
If you've confirmed that your max memory variable is set correctly (see earlier in the thread for the command in CrashPlan that allows you to check), then that's all I had to do to solve my problems. FWIW I'm using 4096 MB memory and backing up 3.6 TB. Most of the time the Docker only uses around 1 GB, but it may have climbed during sync and I missed it (which may be why mine was resetting), so if you can spare the memory, might as well set it high.
If you've set the memory correctly, try reaching out to Crashplan support, too - the can take a look at the logs and see if your block sync is failing for another reason.
-
On 5/25/2021 at 8:47 PM, PeteAsking said:
I updated to 6.2.25 also on the weekend. It seems actually a good version. I have had no issues and you can close the advert these days also.
My switch firmware is 5.43.36.12724 and the AP's are now 5.43.36.12724 so unifi have internally made the version numbers the same even though they are 2 different firmware files and sizes. Im sure this wont cause any confusion and be overlooked by anyone at some point in the future.
Despite this it is all working so guess this version is good to go.
Pete
6 weeks later, how goes it? Any problems from the upgrade to v6? Anything you like about it more than v5?
I'm too afraid to even upgrade the firmware on my APs to the new v5 from v4 without also making the jump to controller v6.
-
5 hours ago, Lectoid said:
I figured it out. Another docker was using the same port. I changed the Unifi port, but that didn't work. Had to change the port on the other docker.
Just out of curiosity: are you running it as Bridge or Host? Bridge is preferred and will work fine as long as you set the correct ports and then set the hostname for adoption in the settings.
Just go back a page in this topic to see more info on that.
-
5 hours ago, grantt said:
Hi
I keep getting emails saying my Crashplan hasn't backed up for xx days. Checking via the docker gui it clearly is.
There's an update, but this will not install. I assume it's due to this newer version not being installed (is this correct?).Any fix for this?
Thanks
Try restarting the Docker. I believe that should have it upgrade to the latest version (I may be confusing it with another Docker though).
If it doesn't upgrade, try a 'force upgrade' in advanced settings (the toggle switch at the top of the Docker page).
-
On 6/23/2021 at 1:18 PM, Flemming said:
Anyone know what this message is?
See this post:
TL;DR increase the limit using the tips n tweaks plugin. There's no magic number, so don't ask for one. The bigger it is, the more RAM you'll need. However, I have mine set to 2097152 (16 GB RAM, no VMs) and it works well for the number of files I"m backing up (and also Plex).
Learn more about inotify here: https://man7.org/linux/man-pages/man7/inotify.7.html
-
On 6/3/2021 at 9:29 AM, jademonkee said:
My account hasn't backed up for 15 days now because it is constantly "Synchronizing File Information."
Just popping in to say that 30 days later I FINALLY have backups completed again.
Thanks again, everyone, for your help.
-
39 minutes ago, mgutt said:
Is there a reason why this container defaults to "bridge" network? For me it's only reliable with "host" network (else it does not adopt devices after restart).
Mine works fine as Bridge. Never had adoption issues (well, there were some when I had to factory reset my devices and completely nuke the controller install, but that wasn't related).
I have the following ports mapped and am running version 5.14.23-ls76:
EDIT: Be sure to make sure you have the broadcast address set manually in Settings > Controller > "Controller Hostname/IP" too!
-
1
-
-
NEVERMIND I FIGURED IT OUT I'M SO SORRY
I had manually added the CRASHPLAN_SRV_MAX_MEM variable, totally overlooking the one that was there by default, (worse yet: it looks like I had even previously set it to 3072M).
I've now deleted the redundant variable, and changed the original one to 4096M, and the run command now looks like this:
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='CrashPlanPRO' --net='bridge' -e TZ="Europe/London" -e HOST_OS="Unraid" -e 'USER_ID'='99' -e 'GROUP_ID'='100' -e 'UMASK'='000' -e 'APP_NICENESS'='' -e 'DISPLAY_WIDTH'='1280' -e 'DISPLAY_HEIGHT'='768' -e 'X11VNC_EXTRA_OPTS'='' -e 'CRASHPLAN_SRV_MAX_MEM'='4096M' -e 'SECURE_CONNECTION'='0' -p '7810:5800/tcp' -p '7910:5900/tcp' -v '/mnt/user':'/storage':'ro' -v '/boot':'/flash':'ro' -v '/mnt/user/appdata/CrashPlanPRO':'/config':'rw' 'jlesage/crashplan-pro' 1e164b1c891c96fdf57ebe60e63903b41d51d0627f749574909eaa1793643510
So sorry for such a stupid mistake. Thank you for your time, and I apologise for wasting it. -
root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='CrashPlanPRO' --net='bridge' -e TZ="Europe/London" -e HOST_OS="Unraid" -e 'USER_ID'='99' -e 'GROUP_ID'='100' -e 'UMASK'='000' -e 'APP_NICENESS'='' -e 'DISPLAY_WIDTH'='1280' -e 'DISPLAY_HEIGHT'='768' -e 'X11VNC_EXTRA_OPTS'='' -e 'CRASHPLAN_SRV_MAX_MEM'='3072M' -e 'SECURE_CONNECTION'='0' -p '7810:5800/tcp' -p '7910:5900/tcp' -v '/mnt/user':'/storage':'ro' -v '/boot':'/flash':'ro' -v '/mnt/user/appdata/CrashPlanPRO':'/config':'rw' 'jlesage/crashplan-pro' e82c65fd7d8a47d2d87b0de10f6624f4dd8a7c11843e2e204e9ddaa55a3b08d1
EDIT: Just noticed that it has the 3072 value for mem, so here's a screencap of the variable (which I'm failry sure I added) for the server max mem, in case you can see something wrong.
-
5 hours ago, Djoss said:
Even though if you specified 4096M in container config ?
Correct. Container config has CRASHPLAN_SRV_MAX_MEM variable set as 4096M
-
4 minutes ago, bump909 said:
@jademonkee Let us know how it goes. I just ran the java mx command and set it to 8192 as that's what I have set in the container settings. Currently at 17% sync. I've got 28TB in the cloud backup.. so this could take a bit.
The file synchronisation did complete, and then it moved to the next maintenance task. I thought that would be a good time to upgrade to the latest version (as Crashplan support mentioned that I should), so I updated the container and now it's doing a "deep maintenance" with 9 hours remaining.
Curiously, it says it's only found 76.7 GB of backups, so I'm assuming (hoping?) after the deep maintenance it will go up to the correct 3.6 TB - hopefully without another file information sync...
Memory usage is currenlty 828MB
After the restart, "xmx" in /mnt/user/appdata/CrashPlanPRO/log/engine_output.log remains at 3072M
[Support] Linuxserver.io - Unifi-Controller
in Docker Containers
Posted
I just took the plunge. Will report back if anything strange happens.
Something strange happened before I upgraded: the theme went to white (from dark) and it said that some WiFi options I had weren't compatible. I had changed nothing since I last upgraded, so don't know why. Maybe something corrupted in the db (again...)?
So yeah: any problems I face may not actually be due to the upgrade, anyhow.