search

trapexit / mergerfs

a featureful union filesystem
http://spawn.link
Other
4.03k stars 168 forks source link

Permissions issue qBittorrent file creation when preload library is used in docker instance #1310

Closed psyke83 closed 4 months ago

psyke83 commented 4 months ago

Describe the bug

With Arch aarch64 on Raspberry Pi 4B with mergerfs 2.40.1-1, if the preload library is used in conjunction with a qbittorrent docker instance, certain files saved directly to a standard ext4 filesystem will have incorrect (zeroed) permissions, causing the application to fail in various ways.

To Reproduce

docker-compose.yml:

---
version: "3.8"

services:
  qbittorrent:
    image: lscr.io/linuxserver/qbittorrent:latest
    container_name: qbittorrent
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Dublin
      - WEBUI_PORT=8081
      - TORRENTING_PORT=24845
      - LD_PRELOAD=/usr/lib/mergerfs/preload.so
    volumes:
      - /usr/lib/ld-linux-aarch64.so.1:/usr/lib/ld-linux-aarch64.so.1:ro # <- preload library fails to work without this additional bind mount
      - /usr/lib/mergerfs/preload.so:/usr/lib/mergerfs/preload.so:ro
      - ./testdocker/qbittorrent/config:/config
      - /mnt/merged/Media:/media # <- not necessary to reproduce
      - /mnt/usb:/mnt/usb # <- not necessary to reproduce
    ports:
      - 24845:24845
      - 24845:24845/udp
    restart: unless-stopped

Method to reproduce: N.B. The testdocker folder is on a standard ext4 filesystem of my Pi's SD card, i.e. not a mergerfs mount.

$ docker compose stop qbittorrent
$ sudo rm -r testdocker
$ docker compose up -d qbittorrent
$ find testdocker/qbittorrent -perm 0
testdocker/qbittorrent/config/qBittorrent/categories.json
testdocker/qbittorrent/config/qBittorrent/rss/feeds.json
testdocker/qbittorrent/config/qBittorrent/GeoDB/dbip-country-lite.mmdb
testdocker/qbittorrent/config/qBittorrent/watched_folders.json

qBittorrent will appear to work correctly at first: torrents can be added, and files can be successfully written to the mergerfs mount at /mnt/merged/Media, but the .torrent and .fastresume files saved to testdocker/qbittorrent/config/qBittorrent/BT_backup are also created with zero permissions. This results in sucessfully or partially downloaded torrents disappearing from qbittorrent's torrent list on the next restart of the docker container (even though the actual completed or partial files will be present on the mergerfs volume with the correct permissions).

Expected behavior

When the preload library is not used, the aforementioned config files in testdocker are created with the standard 644 permissions and none of the problems are encountered.

System information:

Additional context

I am using several other docker containers such as firefox, sonarr, jellyfin, etc., and I haven't noticed any anomolous behaviour (including this kind of permissions issue) when using the preload library with a mergerfs volume.

Edit 1: I can also reproduce the issue on standard Arch x86_64 (Linux hp255g7-arch 6.7.6-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Fri, 23 Feb 2024 16:32:48 +0000 x86_64 GNU/Linux, mergerfs v2.40.1) using the same docker-compose.yml as above, but no mergerfs mount is defined or active on the system at /mnt/merged or anywhere else, thus reinforcing the point that the problem is not related to any mergerfs mount configuration.

trapexit commented 4 months ago

Probably something to do with a specific arm call. I don't have a Pi4. I'll have to see if any of my SBCs are ARM64 to check.

trapexit commented 4 months ago

It'd help me a lot if you provide a strace of qbittorrent when this happens.

psyke83 commented 4 months ago

If you check my edit in Additional context, I was able to reproduce the issue on Arch x86_64, so I think we can eliminate ARM as a factor.

I didn't provide a strace initially, as I wasn't sure how to capture the strace at the right time for a docker-launched process, so here's a strace captured from a standalone launch of qbittorrent.

Steps to reproduce

$ killall qbittorrent
$ rm -rf .local/share/qBittorrent/ .config/qBittorrent
$ strace -fvTtt -s 256 -o /tmp/qbittorrent.strace.txt -E LD_PRELOAD=/usr/lib/mergerfs/preload.so qbittorrent
(Accept legal notice and close app)
$ find .local/share/qBittorrent/ .config/qBittorrent -perm 0
.local/share/qBittorrent/GeoDB/dbip-country-lite.mmdb
.config/qBittorrent/categories.json
.config/qBittorrent/rss/feeds.json
.config/qBittorrent/watched_folders.json

To reiterate, there is no mergerfs mount active on my system, and the .local and .config folders are on a standard ext4 volume.

strace log captured via above steps: qbittorrent.strace.txt

trapexit commented 4 months ago

To reiterate, there is no mergerfs mount active on my system,

Sure. This is to do with the preload.

Thank you for the trace. It's almost certainly due to qbittorrent using O_TMPFILE. I'll see what I can do about it.

trapexit commented 4 months ago

What OS package are you using? I'll build one for you to test changes.

psyke83 commented 4 months ago

I'm using mergerfs built locally via the Arch AUR (on the aarch64 and on x86_64 alike). If it's easier for you, I can make a test build myself if you point me to the diff or test branch.

trapexit commented 4 months ago

Branch preload-tmpfile

psyke83 commented 4 months ago

Tested preload-tmpfile on both x86_64 and aarch64, and it seems that the problem is resolved. Repeating the steps above, the files previously created with missing permissions are now created with the expected permissions. I tested the build against qbittorrent in docker for aarch64 and both qbittorrent docker and standalone qbittorrent for x86_64. Many thanks!

trapexit commented 4 months ago

Addressed in v2.40.2