-
|
LRR Version and OS Version 0.8.4, "Real Cool World", difegue/lanraragi:latest, digest=71e2bc9dd557 My ACL Type is NFSv4, and here's my working ACL:
Notice that UID and GID for apps are both 568: I set the Docker environment LRR_UID=568, LRR_GID=568. Bug Details
Then, LANraragi is able to load thumbs, but failed to load content
However if I give everyone the read permission, it recovers.
Condering that my other apps have the permission to read&write after using UID=568, I'm wondering if the app itself has used permissions other than given 568. P.S. I entered the container and did the test below when everyone have no read permission, apps have full control: /home/koyomi/lanraragi/content # ls -la | grep test
-rwx------ 1 1000 1000 52 Mar 23 16:26 test_permission
-rwx------ 1 1000 1000 0 Mar 23 16:25 test_permission.bak
/home/koyomi/lanraragi/content # id
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
/home/koyomi/lanraragi/content # cat test_permission
If you can see this, you have the read permission.
/home/koyomi/lanraragi/content # su koyomi
~/lanraragi/content $ id
uid=568(koyomi) gid=568(koyomi) groups=568(koyomi),568(koyomi)
~/lanraragi/content $ cat test_permission
If you can see this, you have the read permission.
~/lanraragi/content $ id
uid=568(koyomi) gid=568(koyomi) groups=568(koyomi),568(koyomi)
~/lanraragi/content $ echo "write by 568" >> test_permission
~/lanraragi/content $ cat test_permission
If you can see this, you have the read permission.
write by 568Also, if I give everyone the read permission, I not only the reading function recovered, I can use the Add Archive function as normal without any error. In that case, I am pretty sure that some hidden application(maybe Minion or something) are working as a user other than LRR_UID I gave. Do you have any ideas? Matching Logs |
Beta Was this translation helpful? Give feedback.
Replies: 7 comments
-
|
The UID/GID setup is done through I'm seeing that files in your content folder are 1000/1000: The container doesn't change permissions for the content folder anymore since I had some reports from users that didn't want the folder modified in any way, so you have to make sure on your own that files added to the folder are readable by 568/568. |
Beta Was this translation helpful? Give feedback.
-
Yes I got.
I apply file permissions recursively everytime I change the permission. And as you can see, test_permission is definitely readable and writeable in the container, though I do not know if I ran htop in the container, and it shows as follows, only root and koyomi is involved. Also, this is the logs when the problem occurs, two launchers have high CPU usage, maybe that can help locate the probelm.
The log is usual, if I did not enter any commic book, it keeps silent, until I entered two, and it keeps telling me he do not have permission.
I gave read permission to root, and it does not help. I still need to give everyone read permission. Also a strange thing, the log gives but I can If I remove apps(568)'s permission from the ACL, it directly gives: That's what I expected in the situations that I misconfigured the ACL(file permission). |
Beta Was this translation helpful? Give feedback.
-
|
Are there anyway to just test the permissions inside of the conatiner, or more detailed log gives which part of the program is denied from reading? |
Beta Was this translation helpful? Give feedback.
-
|
Weird. When I change both owner and owner group to 568, configuration like follow works
The change of owner does no matter in my situation, so I can take it as a solution. Do you have any further ideas about how the owner affects the read permission? Is it something related to Perl? I may dig into it latter. |
Beta Was this translation helpful? Give feedback.
-
|
The launchers with high CPU usage are likely the minion workers (which sadly are undistinguishable from the webserver workers with the current setup if you don't have their PIDs), since they now take the blunt of the archive extraction/thumbnail work. As for the logs, they are as detailed as they can be if you're already in debug mode; I'd say the linecounts are enough info on their own: LANraragi/lib/LANraragi/Utils/Archive.pm Line 309 in 9995d70 This confirms that the issue does happen in extract_single_file, which is used by the workers when building thumbnails.
Great that you found a solution tho! I'm not sure this is a Perl problem since the call that's breaking is the one using libarchive, which is fully native. I'm admittedly not an ACL expert or anything so I have no further ideas, sadly. 😅 |
Beta Was this translation helpful? Give feedback.
-
|
After looking into Archive::Libarchive::Peek, I completely have no idea what's going on. Since I have found a workaround, I will just leave this issue. For those who may see this issue, my logs: When I change the ACL before startup. Behaviour: thumbnails shown, content unreadable. When I change the ACL during the running process. Behaviour: thumbnails not shown, content unreadable. P.S. Thanks @Difegue quite a lot. LANraragi really receives a lot of support. And LANraragi almost beats my https://github.com/xiazeyu/hentaiTagger4calibre project. But I'm happy using it. Please keep working on it! |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the kind words and all the detail! 🙏 |
Beta Was this translation helpful? Give feedback.
Weird. When I change both owner and owner group to 568, configuration like follow works
The change of owner does no matter in my situation, so I can take it as a solution. Do you have any further ideas about how the owner affects the read permission? Is it something related to Perl? I may dig into it latter.