verbumfeit
commented
6 years ago Cleanup now works, thank you!
The permission issue persists though, let me know if I can provide additional information to help.
Closed verbumfeit closed 6 years ago
verbumfeit
commented
6 years ago Cleanup now works, thank you!
The permission issue persists though, let me know if I can provide additional information to help.
evilhero
commented
6 years ago If it only occurs during metatagging, then I would think that it could be a perms issue. Since mylar copies the file from the original location to the cache, it might be not be inheriting perms properly, or the user running mylar might not have enough perms to do one of the actions. I believe mylar takes the existing perms and uses this on creation (when copying from the original location to the cache during metatagging)
What are the perms/owmership of the cache mylar_xxxxx folder and file(s) inside?
verbumfeit
commented
6 years ago The mylar_xxxxx folder always has 700 perms and verbumfeit:comics ownership, which is the user:group mylar is running under.
The file inside has 666 perms at first, owned by sabnzbd:comics, which is the user:group sabnzbd is running under. After tagging (I presume) the perms are set to 600, with verbumfeit:comics ownership.
Both users verbumfeit and sabnzbd are members of the comics-group.
evilhero
commented
6 years ago Because it initially copies the file from the original sab location to the cache, it would also copy the existing ownership/permission (which in this case would be sabnzbd:comics / 666). It then performs metatagging by creating the tmp dir with 700 perms (this is due to the mkdtemp command that Mylar utilizes). It then unzips the file, and recreates a new file - with the identical permissions (0600) I would imagine since it's a straight file creation. Then it moves the file to the destination, and tries to chown/chmod it. So if I'm following this right, the user running mylar (verbumfeit) would not have the proper authority to perform a chown since it's owner-based, and not a group-based command.
Again, I'm not 100% sure exactly what's going on - it would seem to imply something with the perms is stopping it from chmodding/chowning the file properly after the initial metatag. All of this is probably in large part due to the restrictive nature of the temp file usage that Mylar uses. Since only the user who created the tmp dir can alter the ownership (not the group, just the owner) - it might be restricting it that way too. I might be able to force a chmod on the file while it's in the tmp directory, and then when it gets moved to the series folder it could be applied properly.....
(sorry for rambling, was trying to work thru this in my head while typing and think I got more confused than not)
EDIT. Actually can you verify the permissions on the file that's moved to the series directory (the one it's trying to chmod/chown and not doing). Since that would be the problematic file, it'd be good to verify that that's correct. The owner stays the same, so it should still be able to perform a chown/chmod you would think.
verbumfeit
commented
6 years ago The file in the series directory has 600 and verbumfeit:comics permissions. So it should have no problems executing the chmod.
I discovered that mylar calls the setperms(path, dir) function during post-processing only once with dir=False argument (which should be correct, since we just downloaded and created a file). Then os.walk(path) is called with path being /comicdirectory/DC Comics/Aquaman/Aquaman 011.cbz, so the variables for dirs and files stay empty and the chmod/chwon never gets executed. See here: https://github.com/evilhero/mylar/blob/cd5bbfe74b807586a07707aea7886d32f8401885/mylar/filechecker.py#L1395-L1403
What would work is replacing the code above with this for the folder (If we really need it here, since it's only a file we want to chmod/chown):
permission = int(mylar.CONFIG.CHMOD_DIR, 8)
os.chown(os.path.dirname(path), chowner, chgroup)
os.chmod(os.path.dirname(path), permission)And this for the file:
permission = int(mylar.CONFIG.CHMOD_FILE, 8)
os.chown(path, chowner, chgroup)
os.chmod(path, permission)I don't know if this would break something else, especially since we have the same block of code again a few lines down: https://github.com/evilhero/mylar/blob/cd5bbfe74b807586a07707aea7886d32f8401885/mylar/filechecker.py#L1395-L1414
EDIT: I wrote a fix that won't break existing functionality. Have to check if it works properly when I get home, then I will submit it :) EDIT2: Here we go: #1870
verbumfeit
commented
6 years ago Fixed with e1e2916f07a15545ebacbfa94886eec8b87a9e40
I have activated the 'Enable Completed Download Handling' option, no category set for sabnzbd, the 'move' option and tagging enabled for post-processing. Renaming is not activated. The Post-processing seems to work fine, converts to .czb, tags it and moves it to my comic directory, but the .cbr file from the sabnzbd completed folder does not get removed and the .czb in the final directory has 600 permissions instead of the configured 664.
If I disable meta-tagging, everything works as expected. I'm on the latest development branch.
Here's the debug log: