Djoss

What was this entity ? By default the app is running under the correct user (nobody/users). My guess is that the files that didn't have the correct ownership were create by another app that was not running under this user ?

The current beta key is expired. We need to wait for the MakeMKV author to publish a new one. See https://github.com/jlesage/docker-makemkv#expired-beta-key

How do you reproduce this ?

In container's setting, you need to add a new "Path". This path should be R/W and will be used to store the local backup. When you create the path, you map a path in unRAID to a path inside the container. Inside the container you can simply use something like "/localbackup".

The enterprise version exists for a while, but I added the unRAID template recently. Good timing

No. Are you able to confirm with your logs if failure started with version 23.10.1 (released on October 20) ? Also, can you confirm if the filesystem you use supports xattr ?

Looks like xattr is no supported by your filesystem ? In container's settings, you may try to add "-no-xattr" to "Custom Options".

Yes, a new image with HandBrake 1.7 is now available.

Did you try to contact the CrashPlan support team ? Maybe there is an issue their side ?

Did you check in service.log.0 ?

So if the file is changing location/directory, you need to make sure this is done under the same mount point inside the container. To better understand, maybe you can provide an example.

The amount of memory needed directly depends on the amount of data you have to backup, something that probably increases with time. CrashPlan suggests to allocate about 1GB per TB of backup data.

Incident can be followed here: https://www.dockerstatus.com

Yeah it seems to have an issue with the Docker Hub: images can't be pulled right now... This is what I have if I try to manually pull the image: docker pull jlesage/crashplan-pro Using default tag: latest Error response from daemon: Get "https://registry-1.docker.io/v2/": EOF

Do you mean that the file is moved to a new location ?

You should save videos under /output instead. By default, the mapping to /storage is read-only. Yes something needs to be incorrectly configured. Can you share the container's config ?

Is it working when encoding with the same preset with the GUI ? Also, you may look at /mnt/user/appdata/HandBrake/log/hb/conversion.log to see if there is more details.

This issue has been seen in the past and people reported that a reboot of the host fixed the problem.

You can remove the setting by enabling the "Advanced View" (top-right corner in container's setting). But note that even if you remove the mapping, the /output folder inside the container will still be there.

Are you trying to have 2 "outputs? If yes, you need to add another "Path", that will allow you to add a new folder mapping between the host and the container.

If you google this error you will find that it seems to be a common issue. You may want to try this : https://support.jdownloader.org/Knowledgebase/Article/View/fix-jdownloader-installation I guess that using the default theme may also be a workaround.

This is normal. The current beta key is expired and a new one is not available yet. It can take few days before a new key is made available by the author of MakeMKV.

The paths used in movie/series/music formats should set according to the point of view of the container. For example, according to your configuration, you should use "/output/musique/{emby}" instead of "/mnt/user/medias/musique/{emby}".

Yes, you just need to configure your preset to keep all tracks. This is basically under the Audio/Subtitles tab, then "Track Selection".

The files should not be owned by root. The should be owned by "nobody/users". You can use "Tools -> Docker Safe New Perms" to restore standard unRaid permissions to your files.