Final File's Permissions Set to 0

Get help, report and discuss bugs.
Post Reply
whisp
Posts: 5
Joined: 04 Oct 2016, 20:35

Final File's Permissions Set to 0

Post by whisp » 14 Aug 2018, 14:43

Setup:
  • NZBGet v20.0 (running in Docker)
  • Pipeline:
    • NZBGet ->
    • PP script: mkvdts2ac3.py (extracts DTS audio, converts to AC3, and remuxes into container) ->
    • PP script: VideoSort (move final files to output folder)
  • Synology NAS

Issue:
Final output files are set to permission `0`. The issue is intermittent (does not happen with all files), but consistent (I can reproduce it with the same file over and over).


Notes:
  • Files in NZBGet's temporary `_unpack` folder are set to `777`
  • When the file is being transferred by VideoSort, both the original and the copy are set to `777`
  • Once VideoSort is done transferring, the copied file is somehow set to `0`
--
  • I've tried playing with the umask setting in NZBGet (both `0` [which should = `777`] and `022` [which should = `644`]), but that did not seem to make a difference.
  • I have tried downloading & PPing a file (that is set to `0`), chmod'ing that file to `777`, copying that file back to the downloads directory, and then re-PPing the file. It still ends up as `0` after being copied by VideoSort.

Do you have any suggestions? The strangest part for me is that the issue is intermittent — does not happen to all files — but consistent — it will happen to the same file over and over. I am happy to provide more info/logs and test things.

hugbug
Developer & Admin
Posts: 7645
Joined: 09 Sep 2008, 11:58
Location: Germany

Re: Final File's Permissions Set to 0

Post by hugbug » 15 Aug 2018, 02:52

Is the final location on the same or different drive? In the latter case VideoSort creates new file and copies content there. That can be a code place where permissions are reset.

whisp
Posts: 5
Joined: 04 Oct 2016, 20:35

Re: Final File's Permissions Set to 0

Post by whisp » 15 Aug 2018, 13:13

hugbug wrote:
15 Aug 2018, 02:52
Is the final location on the same or different drive? In the latter case VideoSort creates new file and copies content there. That can be a code place where permissions are reset.
The final location is on the same drive.

whisp
Posts: 5
Joined: 04 Oct 2016, 20:35

Re: Final File's Permissions Set to 0

Post by whisp » 20 Aug 2018, 16:22

Hugbug, do you have any suggestions for how I can troubleshoot this?

whisp
Posts: 5
Joined: 04 Oct 2016, 20:35

Re: Final File's Permissions Set to 0

Post by whisp » 19 Sep 2018, 13:26

Hugbug, I have new information:

Code: Select all

info	Wed Sep 19 2018 05:59:45	Collection {media-name-removed} added to history
info	Wed Sep 19 2018 05:59:44	Post-process-script videosort/VideoSort.py for {media-name-removed} successful
info	Wed Sep 19 2018 05:59:42	VideoSort: Deleted: /downloads/movies/{media-name-removed}
info	Wed Sep 19 2018 05:59:41	VideoSort: Deleted: /downloads/movies/{media-name-removed}/8d5bcd6f4d89de905b2bd18771e2339d.30
info	Wed Sep 19 2018 05:59:41	VideoSort: Moved: /media/Movies/{media-name-removed}.mkv
detail	Wed Sep 19 2018 05:59:41	VideoSort: Rename failed ([Errno 18] Cross-device link), performing copy: /media/Movies/{media-name-removed}.mkv
info	Wed Sep 19 2018 05:46:36	VideoSort: Detected obfuscated filename Aes0HkmV36gtWkj9qHHmsOTSE.mkv, removing from guess path
info	Wed Sep 19 2018 05:46:32	Executing post-process-script videosort/VideoSort.py for {media-name-removed}
Based on the above log, VideoSort seems to be detecting the destination as being on a different drive than the origin (even though they are on the same physical HDD) in the line including `[Errno 18] Cross-device link`. Is my interpretation correct? Does that help at all?

Post Reply

Who is online

Users browsing this forum: Google [Bot] and 53 guests