Fix for SELinux-related errors

[Tokarak]

If you are getting these errors when trying to start the container:

mkdir: can't create directory '/config/qBittorrent/': Permission denied
/entrypoint.sh: line 29: can't create /config/qBittorrent/config/qBittorrent.conf: nonexistent directory
sed: /config/qBittorrent/config/qBittorrent.conf: No such file or directory
chown: /downloads: Permission denied
chown: /config: Permission denied
Could not create required directory '/config/qBittorrent/cache'

then you have an issue with SELinux. I had this issue running on Podman in RHEL9, with default "enforcing" mode in SELinux.

Fix in docker-compose.yml:

     volumes:
-      - ${QBT_CONFIG_PATH}:/config
+      - ${QBT_CONFIG_PATH}:/config:Z
-      - ${QBT_DOWNLOADS_PATH}:/downloads
+      - ${QBT_DOWNLOADS_PATH}:/downloads:Z

I think this should be added to the docs, or enabled by default.

[Chocobo1]

The whole SELinux seems rather painful to setup. Anyway it is good that you have filed the issue. I'm sure others that encountered the same issue is able to find your info.

I think this should be added to the docs, or enabled by default.

It seems :Z, :z has more implications than just mounting it: https://unix.stackexchange.com/questions/728801/host-wide-consequences-of-setting-selinux-z-z-option-on-container-bind-mounts I'm not sure this is the correct solution but I don't have much experience with SELinux.

ps. I'm inclined to close this issue since SELinux is out of the scope of this project...

[Tokarak]

As only the qBittorrent should write to the bind-mounts, :Z is the correct option, unless there are more than one instances of qbittorrent sharing the same config/downloads folder.

PS: Closing the issue is fine, I just thought the README should be updated before closing.

[Chocobo1]

:Z is the correct option, unless there are more than one instances of qbittorrent sharing the same config/downloads folder.

Won't it prevent the host from accessing the folders? At least this was the impression from the stackexchange link above.

[Tokarak]

Won't it prevent the host from accessing the folders? At least this was the impression from the stackexchange link above.

Yes, that's true. I kept it since technically the host should not write to the folder either. It did make torrent creation hard (it's already hard on qbittorrent-nox), but there is podman cp, for example.

So, using :z would avoid all these problems? With no drawback as far as I can see. I didn't test yet.

[Chocobo1]

I kept it since technically the host should not write to the folder either.

Do you mean the host can still read it but cannot write it? If the host cannot read it then it is unexpected to me. Just curious, how do you read/write to the folders? with podman cp?

So, using :z would avoid all these problems? With no drawback as far as I can see. I didn't test yet.

If I understand correctly, it only allow sharing the mount between containers. Everything else would be the same as :Z.

[Tokarak]

With :Z the mask and SELinux context is -rw-r--r--. 1 100999 100999 system_u:object_r:container_file_t:s0:c167,c843 with :z, -rw-r--r--. 1 100999 100999 system_u:object_r:container_file_t:s0 So only the category is changed. 100999 is Podman's user or something like that. Changing the mask recursively to 777 might work? I don't want to try it, it's not very secure.