Djoss

The first screenshot you provided doesn't seem to come from the container's UI... is it the case?

The latest Docker image fixes the issue.

Please verify/confirm that /mnt/user/appdata/FileBot/license.psm is the right license. If yes, you should contact FileBot support directly, since the issue seems to be the license itself.

@Trylo, @Boyturtle, I'm looking at solutions to this. The cause of the issue is known: CrashPlan changed the location where pipes are created for restore operation. As workaround, running CrashPlan as root (set the User ID and Group ID in container settings to 0) should work.

You clan clear the cache with this method: https://github.com/jlesage/docker-crashplan-pro#device-status-is-waiting-for-connection

Could you provide the output of: docker exec FileBot /opt/filebot/filebot -script fn:sysinfo

Just to be clear, I'm not talking about Firefox itself, but the browser you use to access the Firefox container.

Do you have a typo somewhere ? The error message says "/stroage" instead of "/storage".

Did you try to clear your browser's cache?

Normally, when you close all tabs, Firefox exits an cause the container to also stop. To avoid this, you can edit the container's setting and add a variable "KEEP_APP_RUNNING" and set its value to "1".

Try to clear your browser's cache.

Not sure if you saw the answer on GitHub, but I would try to add the following under "location": error_log off; access_log off;

No, this is not something that can be configured with NPM.

The 502 error seems to indicate that NPM cannot reach pihole. Double check you proxy host settings.

I think that deleting the certificate will also revoke it.

According to the error, NPM was not reachable through port 80 from the Internet. Did you verified this ?

The 504 error seems to indicate that NPM cannot reach your Jellyfin container...

@Shonky, thanks for reporting the issue. I will try to see what can be done to fix this.

The "docker run --rm jlesage/firefox" command didn't show that Firefox crashed. So normally, re-installing the container with default settings and removing /mnt/user/appdata/Firefox should do the trick.

This seems to be the expected behaviour: HandBrake will try to use all available cores during the encoding.

Sorry for the delay. I updated the GitHub issue. Basically, this seems to be an issue with the Intel Media Driver. Once a new driver with the fix is released, it will be integrated into the Docker image.

Looks like a temporary issue with the opensubtitles.org site/api. For how long do you have the issue ?

Ok. You can check under Tools->History to see if there is any indication. Else, you can check in log file located at /mnt/user/appdata/CrashPlanPRO/log/service.log.0

If it's working inside a private window, it usually means that there is a cache issue with the browser. Did you try with Chrome ? When using a VNC client, make sure you connect to the VNC port (7906).

Do you have configured a backup schedule in CrashPlan ?