Weird permission issues with tvnamer
My show downloading stack lives on. I’m curious as to which will happen first: NetFlix hits Israel, or I switch over to Sick Beard.
At any rate, nowadays I use flexget
, transmission
, tvnamer
and xbmc
, held together with some bash scripts. On debian- and ubuntu-based systems, the transmission
daemon runs as a separate user (debian-transmission
), so this requires a bit of care with file and group ownership. After rebuilding my system, I couldn’t get tvnamer
to work right for some reason, no matter how careful I was. I’d keep getting this error:
|
|
For a few weeks I’d double-check the permissions, fail to understand what was going on, groan and copy the files manually. The new Sherlock episode had me in a bit of a more investigative mood.
This turns out to be an exercise in confusing OS logic and logging. It looks like the rename operation failed, and somehow the directory creation failed as well. Neither is the case. A hint can be found in the precise error after the rename: “1 - Operation not permitted” (that’s EPERM
). If that seems a bit off, that’s because it is: When renames fail because of inadequate permissions, they return EACCES
“13 - Permission denied”. So what’s going on?
It turns out that after renaming, tvnamer
tries to preserve the access and modification times of renamed files. A noble cause, but it turns out that Linux won’t allow this unless you are the owner of the file - even if you do have write permissions. Therefore, this fails, which causes tvnamer
to believe the rename failed - although it hasn’t. Afterwards, the directory is created (this succeeds), but since tvnamer
tries to copy using the old filename (thinking the rename failed), we get an ENOENT
“2 - No such file or directory” error about the source of the copy operation.
The fix can be found in this pull request. Happy bug hunting!