Sickchill: File is locked for reading/writing only during manual post processing

[xalten]

Just recently started having an issue when trying to manual post process. I keep getting File is locked for reading/writing warnings. I have read and know that most of these are due to permissions issues. I tried to chmod 777 the file just to make sure it wasn't permissions and that didn't fix it. Automatic post processing appears to be working fine but so far 2 separate manual post process attempts have done this now.

Branch: master
Commit: 4d69a8e09fe808751fa5fef9a0c3e3b8c1af99b1
Version: 2016.09.10-1
Database Version: 44.0
OS: Fedora Server 22
What you did: Manual post process a folder
What happened: Returned warning File is locked for reading/writing
What you expected: File to be renamed and moved to proper folder
Logs:

2016-09-15 22:58:50 WARNING Thread-13 :: [/storage/Videos/Temp/CompletedShows/xxx/xxx.mkv : Processing failed: File is locked for reading/writing] 
2016-09-15 22:58:50 WARNING Thread-13 :: Problem(s) during processing, failed the following files/folders:  
2016-09-15 22:58:50 WARNING Thread-13 :: Processing failed for /storage/Videos/Temp/CompletedShows/xxx/xxx.mkv: File is locked for reading/writing

[SickRage2]

Thanks for the issue report! Before a real human comes by, please make sure your report has all the below criteria checked

• [ ] Include basic information: Branch/Commit, OS, What you did, What happened, What you expected
• [ ] Enable debug logging (be sure to disable after the bug is fixed)
• [x] Post debug logs, either inline (for smaller logs) or using gist
• [ ] Please wrap inline logs inside and for readability

Please make sure you also read how to create an issue and followed all of the steps.

The title should describe your issue. Having "SR not working" or "I get this bug" for 100 issues, isn't really helpful. We will close issues if there isn't enough information.

Sometimes the devs may seem like grunts and respond with short answers. This isn't (always) because the dev hates you, but because he's on mobile or busy fixing bugs. If something isn't clear, please let us know, and this bot may get updated to automatically answer you.

Thanks!

[neoatomic]

Clearly its a permission issue, so another program is accessing the files, (download client?) or something isn't setup right. You might want to checkout the wiki for some guides.

https://github.com/SickRage/SickRage/wiki/Installation-&-Configuration-Guides

[haarts]

I had the same issue. And I figured it out. For what it is worth my download client (Transmission) runs under the user transmission-debian. Files created by it have that owner and group with the normal 755 permissions. The Post processing (whether manual or otherwise) tries to Move the file _even if you set Symlink_. The symlinking works the other way; it move the file to the destination dir and creates a symlink in the source directory.
I had more luck with the 'Symlink reverse' option.

Hope this helps.

BTW I think a better name for the file operation would be to rename 'Symlink' to 'Move and symlink' and rename 'Symlink reverse' (reverse from which perspective?) to 'Symlink'.

[UStralian]

I had this problem the other day too, and figured it out. Even though the individual files had the correct owner, group and permissions, the parent folder (which I had just created using my non-su ssh login) was not.The folder on which you run the manual post processing has to have the permissions set up too.

I had a whole bunch of other permissions problems a long time ago with SR, CP, HP and SAB. I solved them all using clinton hall's excellent guide here

[marcofranssen]

@UStralian seems the guide is offline and I'm facing the same issue now. Hope you still have a reference somewhere that works.

[musiczetetic]

@UStralian seems the guide is offline and I'm facing the same issue now. Hope you still have a reference somewhere that works.

@marcofranssen that document helped me years ago but when I tried now after a reinstall things have changed too much since it was written. It was much simpler for me this time. I added all the users (sc-sickchill, sc-deluge etc.) to the sc-download group using SSH, then gave appropriate permissions for that group to my download and video folders using File Station in the NAS GUI.

It seems deluge and sickchill are still creating files/folders using their own groups instead of sc-download which I thought was supposed to be used by all synocommunity related apps now.

You can still access that above mentioned guide via the wayback machine if you need to check it out.

[miigotu]

SC changes the file group to whatever group the parent folder is.

[musiczetetic]

That is not my experience with the latest version of SC, I have made all my media folders sc-download owned and SC stil creates a new show with folder owned by group sickchill

[miigotu]

It is supposed to create files/folders with it's own group. Your show folders are supposed to be in the sc-sickchill group. Your downloads are supposed to be in the sc-download group. sc-sickchill is a member of sc-download group.

You are confusing this issue to be synology specific, amd the other people arent using synology. You always needed to set permissions up when sharing files between applications on synology.

[musiczetetic]

Good to know. I have set all permissions as I thought they should be, but I had never found any info before about having to make all show folders owned by sickchill. I solved it by making all users members of sickchill and sc-download groups.