Container could not initialize on a read-only file system

[VxDlH]

First, thank you for your work.

A read-only file system produced these errors:

2024-12-01T23:10:11+00:00| Container started
2024-12-01T23:10:11+00:00|   OS = "Alpine Linux v3.20"
2024-12-01T23:10:11+00:00|   USER = "11000:11000"
2024-12-01T23:10:11+00:00|   JAVA version = "openjdk21-jre-headless-21.0.5_p11-r0"
2024-12-01T23:10:11+00:00|   WARNING "JD_EMAIL" not found
2024-12-01T23:10:11+00:00|   WARNING "JD_PASSWORD" not found
2024-12-01T23:10:11+00:00|   Check "JDownloader.jar"
2024-12-01T23:10:11+00:00|     Delete any existing JDownloader installation files
rm: can't remove './tmp': Read-only file system
rm: can't remove './update': Read-only file system
2024-12-01T23:10:11+00:00|     Download "https://installer.jdownloader.org/JDownloader.jar"
2024-12-01T23:10:11+00:00|     ERROR : curl exited with code "23"
2024-12-01T23:10:11+00:00|   Setup JDownloader
2024-12-01T23:10:11+00:00|     Create directory "./update/versioninfo/JD/"
2024-12-01T23:10:11+00:00|     Install "./update/versioninfo/JD/extensions.requestedinstalls.json"
2024-12-01T23:10:11+00:00|     Set JDownloader email
2024-12-01T23:10:11+00:00|     Set JDownloader password
2024-12-01T23:10:11+00:00|     Set JDownloader devicename
2024-12-01T23:10:11+00:00|   Start JDownloader
2024-12-01T23:10:11+00:00|     JDownloader started [PID=81]
2024-12-01T23:10:11+00:00|     JDownloader stopped
2024-12-01T23:10:11+00:00| Container stopped

This warning seems odd; my environment variables appear to be correctly configured.

 WARNING "JD_EMAIL" not found
 WARNING "JD_PASSWORD" not found

but this point is not a showstopper

jdownloader/src/docker-entrypoint.sh

Line 45 in 1f8738c

elif [ -z "$JD_PASSWORD" ]; then

rm: can't remove error can be fixed by adjusting the line:

jdownloader/src/docker-entrypoint.sh

Line 74 in 1f8738c

rm -f -r $JDownloaderJarFile Core.jar ./tmp ./update

by this one :

rm -f -r $JDownloaderJarFile Core.jar ./tmp/* ./update/*

This issue is optimally resolved using the ./tmp folder

Download "https://installer.jdownloader.org/JDownloader.jar"
ERROR : curl exited with code "23"

jdownloader/src/docker-entrypoint.sh

Line 79 in 1f8738c

downloadFile "https://$JDownloaderJarUrl" "$JDownloaderJarFile"

by this one :

downloadFile "https://$JDownloaderJarUrl" "./tmp/$JDownloaderJarFile"

• Generally, it is recommended to use the system's default /tmp directory for all temporary files.
• If it needs to be emptied, it is preferable to delete /tmp/*.
• On a read-only system, it is easier to create a mount point for /tmp.

[antlafarge]

Hello, I don't understand why you use a read only file system ?
The container needs to create / delete files to work (jDownloader files and downloaded files)
Can you explain what are you trying to do?
Thank you

[antlafarge]

You have to know that ./tmp and ./update folders are created by jDownloader application. So I have no control on this.
And jDownloader.jar is not a temporary file, I delete the file (and linked subdirectory tmp and update) only if the file is corrupted and then re-download it.

[VxDlH]

The directories containing data (configuration directory and download directory) aren’t read-only, but the rest of the system is. This is the best practice when running dockers that have internet access.

[VxDlH]

You have to know that ./tmp and ./update folders are created by jDownloader application. So I have no control on this. And jDownloader.jar is not a temporary file, I delete the file (and linked subdirectory tmp and update) only if the file is corrupted and then re-download it.

That is not a problem. What I suggest is, instead of deleting the directory itself, it is preferable to delete its contents.

[antlafarge]

Okay, for the use of /tmp directory by jDownloader app, I recommand to discuss of that in the official jDownloader forum.

For the warnings, can you share the docker compose or docker run command to reproduce it ?

And for the replacement of rm -f -r $JDownloaderJarFile Core.jar ./tmp ./update by rm -f -r $JDownloaderJarFile Core.jar ./tmp/* ./update/*, I'm not against that if there is an issue.
But before changing anything, I need to understand why the tmp and update directory content can be deleted, but not the directories themselves ?
(the directories are created by jDownloader in the container, so it should be able to be deleted too ?)

[VxDlH]

Okay, for the use of /tmp directory by jDownloader app, I recommend discussing that in the official jDownloader forum.

Okay, no problem with that.

For the warnings, can you share the docker compose or docker run command to reproduce it?

I'm using your image on a Kubernetes cluster.

Here is my simplified file.

kind: Deployment
apiVersion: apps/v1
metadata:
  name: jdownloader
  namespace: jdownloader
  labels:
    app: jdownloader
spec:
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: jdownloader
  template:
    metadata:
      labels:
        app: jdownloader
    spec: 
      securityContext:
        runAsUser: 11000
        runAsGroup: 11000
        fsGroup: 11000
        seccompProfile:
          type: RuntimeDefault
      containers:
        - image: antlafarge/jdownloader:alpine-openjdk21
          securityContext:
           allowPrivilegeEscalation: false
           readOnlyRootFilesystem: true
           runAsNonRoot: true
           seccompProfile:
             type: RuntimeDefault
           capabilities:
             drop:
             - "ALL"
          name: jdownloader
          ports:
            - containerPort: 3129
              name: myjd-access
              protocol: TCP
          envFrom:
            - configMapRef:
                name: "jdownloader-config"
            - secretRef:
                name: "jdownloader-myjd"
          volumeMounts:
            - mountPath: /jdownloader/cfg/
              name: config
            - mountPath: /jdownloader/update/
              name: update
            - mountPath: /jdownloader/logs/
              name: logs
            - mountPath: /jdownloader/tmp
              name: tmp
            - mountPath: /jdownloader/downloads/
              name: downloads
      volumes:
       ...

• The /jdownloader directory is read-only.
• The /jdownloader/cfg/, /jdownloader/update/, /jdownloader/logs/, /jdownloader/tmp, and /jdownloader/downloads/ directories are read-written.

It is not possible to delete the directories /jdownloader/cfg/, /jdownloader/update/, /jdownloader/logs/, /jdownloader/tmp, and /jdownloader/downloads/ . However, their contents can be deleted.

The system is designed to be read-only, except for the areas I've specifically chosen to make writable.

[antlafarge]

Okay you spotted a bug in the JD_EMAIL and JD_PASSWORD environment variables checks, I fixed it and re-deployed fixed images on DockerHub. That's strange nobody reported this bug before. Thank you!

And I see what you tried to do, but /jdownloader has to be writable, because the container downloads and starts the jdownloader.jar file in this directory. So I recommend you to simplify your volumes settings and put /jdownloader directory as writable and remove all your subdirectory volumes. I don't see any interest to put subdirectories as writable and not /jdowloader itself?
(If I fix the rm command to clean the content of update and tmp, it will continue to fail because it can't download and write jdownloader.jar in /jdownloader directory)

[VxDlH]

ok Thx

[antlafarge]

Thank you for your participation, it is very useful for me.
If you see anything else to improve (in the project, source code, or in the doc), do not hesitate to share your experience.

[vnghia]

@antlafarge It seems that read only filesystem is still not working for me :/ In my case, only a mounted volume is writable, everything else is read-only. So if I do a bind-mount /test:/jdownloader, it will effectively overwrite all the files that resides inside /jdownloader :/ Could we address this behavior by changing the location of these files I guess.

Thank you very much!

[antlafarge]

Hello, thank you for your concern.
Can you explain what and why you want to do this? (use cases)
And what you need to be changed in the project to support this ?
Thank you !

[VxDlH]

For security reasons.

Docker images are inherently read-only, meaning that once an image is built, it cannot be modified. However, when a container is created from an image, it can be run in a read-only mode, which prevents any changes to the container's filesystem unless explicitly allowed through volumes or tmpfs mounts.
This read-only mode is often used for security and consistency, ensuring that the container's filesystem remains unchanged during its runtime.

Security Benefits: Running containers in read-only mode reduces the attack surface by preventing unauthorized modifications to the filesystem. This is particularly useful in production environments to ensure that the container's state remains consistent and secure throughout its lifetime.

This is a fundamental principle of Docker images, but one that seems to have been forgotten in many projects.

[vnghia]

Hi @antlafarge, thanks for reopening this issue. Thank @VxDlH for an explaination here. Essentially it boils down to:

It can be run in a read-only mode, which prevents any changes to the container's filesystem unless explicitly allowed through volumes or tmpfs mounts.

In a simpler term, for any given path /root/path/, the container can only write to that path if it is bind-mounted by a volume of a tmpfs. In our case, the container writes to /jdownloader but also we use the file /jdownloader/docker-entrypoint.sh (the entrypoint).

So we can not bind mount a volume (-v jdownloader-volume:/jdownloader) because then the file /jdownloader/docker-entrypoint.sh will be overwritten with the content of the volume. I think the best way here is to download jdownloader.jar to a subfolder e.g /jdownloader/jar/ so we can bind mount the -v jdownloader-volume:/jdownloader/jar instead.

Thank you very much!