[Bug]: qBitManage can't move files it doesn't own even with proper group permissions about qbit_manage HOT 7 CLOSED

Docker compose as well and ls -lha of the problem file from in the container

from qbit_manage.

Docker compose as well and ls -lha of the problem file from in the container

Compose:
https://gist.github.com/datcactus/308bb312c618bdc13c32bd780ca41644

ls -lha of problem file (where 1000 is just my standard cactus user that created the file, and hotio is the mapped 1215 from the container's perspective):

cc23d92ef6fa:/$ ls -lha /data/torrents/tv/cactus-test.txt
-rw-rw-r-- 1 1000 hotio 48 Jul  7 20:26 /data/torrents/tv/cactus-test.txt

Directory perms since they're relevant when using mv (where hotio:hotio is 1009:1215):

cc23d92ef6fa:/data/torrents# tree -pugd -L 1
[drwxrwxr-x hotio    hotio   ]  .
├── [drwxrwxr-x hotio    hotio   ]  audiobooks
├── [drwxrwxr-x hotio    hotio   ]  books
├── [drwxrwxr-x hotio    hotio   ]  cross-seed
├── [drwxrwxr-x hotio    hotio   ]  isos
├── [drwxrwxr-x hotio    hotio   ]  movies
├── [drwxrwxr-x hotio    hotio   ]  music
├── [drwxrwxr-x hotio    hotio   ]  orphaned_data
└── [drwxrwxr-x hotio    hotio   ]  tv

from qbit_manage.

Looking at the code it seems likely this fails as the orphaned file logic attempts to set the last modified time on the file (to facilitate recycle bin cleanup) which requires owning the file.

from qbit_manage.

@bakerboy448 Interesting. I wonder if there's some way that os.utime works that's different than a standard touch.

From the container, a standard touch seems to work just fine to update times:

2b57880f8a72:/data/torrents/tv$ stat cactus-test.txt
  File: cactus-test.txt
  Size: 62              Blocks: 17         IO Block: 131072 regular file
Device: 0,51    Inode: 7667        Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/ UNKNOWN)   Gid: ( 1215/   hotio)
Access: 2023-07-08 01:47:07.178065837 -0400
Modify: 2023-07-08 01:47:07.179044102 -0400
Change: 2023-07-08 01:47:07.179044102 -0400
 Birth: -
2b57880f8a72:/data/torrents/tv$ touch cactus-test.txt
2b57880f8a72:/data/torrents/tv$ stat cactus-test.txt
  File: cactus-test.txt
  Size: 62              Blocks: 17         IO Block: 131072 regular file
Device: 0,51    Inode: 7667        Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/ UNKNOWN)   Gid: ( 1215/   hotio)
Access: 2023-07-08 01:48:01.627245932 -0400
Modify: 2023-07-08 01:48:01.627246132 -0400
Change: 2023-07-08 01:48:01.627265162 -0400
 Birth: -
2b57880f8a72:/data/torrents/tv$ id
uid=1009(hotio) gid=1215(hotio) groups=1215(hotio),100(users)

from qbit_manage.

Although it doesn't fix it, but I added a workaround, after copying the file it'll delete the original source so essentially "moving" the file by copying/deleting the original. Let me know if that works for you

from qbit_manage.

@bobokun I think as long as it can cleanup the file it's a decent workaround, but I'm mostly just confused about why a manual touch works just fine but the one being performed by os.utime has a strict permission requirement or some other underlying issue. Is there another way that the function could be constructed such that it doesn't have to directly perform that call on the file? Or, is this something that would be caused by having atime disabled on the underlying NFS share that feeds my media? A standard touch command works fine even with atime disabled so I'm not really sure how to debug this further.

There should be a way to get this to work with group permissions. While this doesn't present an issue for someone who just runs everything as root or 1000:1000 it's problematic in an environment where individual apps have their own user (or in this case qbit and qbitmanage run as the same qbit user) for their volume permissions and shared data access is managed via a shared group.

from qbit_manage.