ljm42

I opened the console for the first time in a long while (I usually just use SSH) and was greeted with a screenfull of this: getfattr: Removing leading '/' from absolute path names getfattr sounds like it is related to this plugin, is anyone else seeing this?

Here's the thread that talks about the differences between the Plex containers: https://lime-technology.com/forum/index.php?topic=41562.0

Yes I know what the article is for, I'm literate. I tried the crashplan desktop container and when I connected to the crashplan container on the same machine, the crashplan service would crash. Every single time. Which I had stated already. I used the tutorial I had linked to connect the crashplan on my unraid box using the crashplan UI on my desktop to configure the former. Please understand we are volunteers just trying to help people out. If you have a problem you want help with, be clear about what it is and provide as many details as you can. When people don't provide any details, about all we can do is ask them to review the directions. I have no idea what would make CrashPlan crash. Docker logs might help. I'll go ahead and throw this out there, just to get it out of the way... The most common mistakes during setup are: * mapping a volume to CrashPlan-desktop (only map volumes to CrashPlan, not CrashPlan-desktop) * failing to add "--volumes-from CrashPlan" to CrashPlan-desktop Then, if CrashPlan-desktop reports "Unable to connect to the backup engine", simply restart the CrashPlan-desktop docker.

No need to reinstall anything, just restart the CrashPlan-desktop container. The issue is that every time the main CrashPlan docker loads, it recreates the .ui_info file in a way that prevents remote connections (this is a "feature" of CrashPlan itself, not a problem with the docker). The CrashPlan-desktop docker is coded to fix it, but that code has to run *after* the main CrashPlan docker has finished loading. I find it easier to disable auto-load for CrashPlan-desktop. I start and stop that docker manually when I want to use it. p.s. - you really need to get a UPS

Yes, everything working fine here.

Congrats on the happy union of plugins!

That sounds good dmacias, thanks for working on this! What do you think of adding secondary triggers? For instance, if the fan speeds increase linearly based on hd temps, perhaps if the IPMI MB temp hits a certain number it could instantly bump all fans to 100% regardless of hd temp? Just trying to figure out how to make use of the other sensors. Seems a shame to have them and not use them

I went ahead and installed the standard Fan Auto Control plugin just to check it out, but I'm having trouble interpreting it. Is this how it works? * Below the Low temp threshold, fan speed is set to the "Minimum PWM value" * Above the High temp threshold, fan speed is set to 100% * Between the thresholds, fan speed increases linearly as the temp increases Is that what it is doing? Assuming I'm on the right track... it appears that this just looks at the motherboard temp. Can we also take hard drive temps (and maybe even the CPU temp) into consideration somehow? Also, the current IPMI Tool plugin can display the RPM of multiple fans, will it be able to control the speed of multiple fans too? Thanks!

I think ipmi-based control over fans would be brilliant. I haven't installed the dynamix one since I can't use it, but you can't go wrong patterning it after something bonienl does It would be nice to replace the Dynamix System Temperature plugin with one that uses ipmi values too. There is a start of a conversation here: https://lime-technology.com/forum/index.php?topic=36543.msg361884#msg361884 but it didn't get any traction.

Good idea, I've added a note.

It really sounds like the transcoding is still being done in the docker image. There are two steps to moving it outside of the docker image: 1) Add a volume mapping for /transcode to /tmp (or a location on your cache drive) 2) In Plex, go to Settings -> Server -> Transcoder. Hit Show Advanced. In the "Transcoder temporary directory" put "/transcode" That should solve it for you. Edit - I expanded on this idea and added it to the Docker FAQ If Plex is your only Docker, and transcoding really is happening outside of the docker image, and you are still getting to 98%, then your docker image is probably just too small. Mine is 20gb.

Good point, this would probably be the best way to upgrade: Stop both the CrashPlan and CrashPlan-Desktop dockers Update the CrashPlan docker, give it is a few minutes Update the CrashPlan-Desktop docker I've gone back in time and updated my last post

This is very cool, I really like the LinuxServer.io approach. Thank you for everything you provide to the community!

As a general rule for community-supplied plugins and dockers, you'll need to be running the latest version in order to get any kind of support. The community members who provide help do so out of their own time, and they don't enjoy troubleshooting problems that have already been fixed So typically the first step in troubleshooting any kind of problem is to ask you to update to the latest version. That's not to say you are required to update everything on day 1. If your system is working and you prefer to wait and see if other people report problems, that is fine. Just know that the longer you wait, the less anyone will remember about the upgrade process in the event you do have problems

You may have better luck asking this on the Plex forum, but I'm guessing you have enabled Plex Home? Once you do that, all users have to authenticate: https://support.plex.tv/hc/en-us/articles/203948786 If you disable Plex Home you should be able to use the "list of networks that are allowed without auth" setting to avoid having to login from your local network: https://support.plex.tv/hc/en-us/articles/200430283 but I don't have much experience with that.

Thank you gfjardim! Today's update to the CrashPlan and CrashPlan-Desktop dockers work great! There is no longer a need to manually upgrade the CrashPlan-Desktop docker. Probably the best way to upgrade is: Stop both the CrashPlan and CrashPlan-Desktop dockers Update the CrashPlan docker, give it is a few minutes Update the CrashPlan-Desktop docker When you start the CrashPlan-Desktop, if you get an "Unable to connect to the backup engine" message, do the following: Answer No to the prompt Modify \\tower\appdata\crashplan\id\.ui_info, changing 0.0.0.0 to 172.17.42.1. It should look something like this when you're done: 4243,aaa-bbb-ccc-ddd,172.17.42.1 Click the CrashPlan icon again to reload it

Hmm I haven't rebooted yet, but this surprises me. The good news is that with docker it is easy to start over. Just delete the container and re-add it.

Based on those error messages, it sounds like the problem is related to step 1: docker exec -it CrashPlan-Desktop bash If that returned an error message of some kind, then the remaining commands will not work. I've updated the instructions to check for this.

Not that I see. I think merging them would solve a lot of problems.

OK, so it sounds like my fix eliminated the "disconnected from backup engine" error and allowed the desktop docker to manage the main CrashPlan docker, right? That is all this fix was trying to do. For help with general setup, see the awesome document that Leifgg posted. But this is still probably not a good time to get started with CrashPlan, too many potential problems right now.

I followed your steps but no luck. When you connect to the desktop docker and see the CrashPlan splashscreen, what version does it say it is loading? If it says 4.4.1, then the manual upgrade worked and there is likely a problem with your .ui_info file. Note - I'm assuming that CP worked for you before? If CP has never worked then this is not a good time to get started with it It would probably be best to wait for an official update. If the splashscreen still says 4.3, then something went wrong with the manual upgrade. You can try SSH'ing to your server and running those commands again, or we can wait and see how it works for other people. I've done this on two servers and it worked fine, but if other people have problems I'll revert one of mine and do the manual upgrade again to check for typos or whatever.

Thanks for that. Will these changes complicate application of the "real" docker update when/if that comes? It won't cause any problems, updating the Docker will wipe out all the manual customizations we made to the container. If you are really concerned about it, you could delete the docker and reinstall it. The .ui_info file is the only modification that happens outside of the docker container. Normally that means it would "stick", but in this case that file is recreated every time you restart the main CrashPlan docker. Same as above, all manual customizations will be wiped out when you update the container.

As of Nov 8, this workaround is no longer needed. Just update to the latest versions of the CrashPlan and CrashPlan-desktop dockers. See this. Here's a quick fix to solve the "disconnected from backup engine" error in CrashPlan Desktop. This updates it to CP 4.4.1 and tweaks the .ui_info file Modifying a docker in this way is typically frowned upon, but it is our only option until the docker itself is updated. SSH to your server and type: docker exec -it CrashPlan-Desktop bash Note: If you see a message that says "Error response from daemon: no such id", then either you made a typo, or you haven't installed the CrashPlan-Desktop container, or you gave the container a different name. Do not continue until you have successfully exec'd into the container. [*]wget -nv https://download.code42.com/installs/linux/install/CrashPlan/CrashPlan_4.4.1_Linux.tgz -O - | tar -zx -C /tmp [*]cd /usr/local/crashplan [*]cat /tmp/crashplan-install/CrashPlan_4.4.1.cpi | gzip -d -c - | cpio -i --no-preserve-owner [*]exit [*]exit * Full disclosure, all I did here was pull the relevant bits out of gfjardim's docker and update for 4.4.1: https://github.com/gfjardim/docker-containers/blob/master/crashplan-desktop/install.sh Now modify \\tower\appdata\crashplan\id\.ui_info, changing 0.0.0.0 to 172.17.42.1. It should look something like this when you're done: 4243,aaa-bbb-ccc-ddd,172.17.42.1 At this point the CrashPlan-Desktop should be able to connect to CrashPlan. If you reboot your server (or otherwise restart the main Crashplan docker), you'll need to modify the .ui_info file again. I believe the other changes will remain intact.

Sorry I wasn't clear. I agree that grouping by PID is important, I was suggesting to change the sort order of the groups. Currently it sorts the groups by PID: PID 17665 - Plex (a group of 30 individual rows) PID 18880 - smbd (a group of 4 individual rows) PIC 19851 - Plex (a group of 10 individual rows) PIC 20281 - smdb (a group of 2 individual rows) If we were to re-sort by Program it would look more like this: Plex - PID 17665 (a group of 30 individual rows) Plex - PIC 19851 (a group of 10 individual rows) smbd - PID 18880 (a group of 4 individual rows) smbd - PIC 20281 (a group of 2 individual rows) I think that would make it easier to see what apps really have open, but if you disagree that is fine. This is still really helpful I was hoping to modify the existing Array Operations tab, rather than create a new one. But maybe that isn't possible without incorporating this into unraid itself. We certainly wouldn't want to break that particular tab

This is awesome! Thank you dlandon (and BubbaQ)! The list is currently sorted by PID, would you consider sorting it by program instead, so all of the Plex processes are together, the smdb processes are together, etc. Also, could this be integrated with the Main -> Array Operation tab? Perhaps by adding a link in the Stop area that shows the number of open files and links over to this tool?