[How-To] Giving Plugins Write Permissions to Your Data

[Joshua Parker Ruehlig]

The windows permission issue is just because for some reason all the files end up with UID 921 instead of guest. I'm not sure if that's a transmission thing or CP thing. As soon as I change the UID to guest they are movable/deletable.

Ok so if I'm doing solution 2:

In the jail, add a user with a matching UID as the owner of the data dataset/folders.

I'm still not sure what the UID should be. What is the UID matching?

These are the only users I have created....

Rest seems pretty self-explanatory. It's just weird because I have no issues with sickrage but CP is giving me issues.

pw useradd -n guest -u UID -d /nonexistent -s /usr/sbin/nologin

1. service couchpotato onestop
2. chown -R guest:guest /var/db/couchpotato
3. sysrc 'couchpotato_user=guest'
4. service couchpotato start

you should have replaced UID with 1001.

 

[Supa]

Hopefully this did it... thx.

 

[whatnissan]

Ok I have no clue what the hell is going on... I fixed this before but now the issue is back. Im still getting permission denied error for transmission and i have changed the user it runs as and file permissions and whatever the hell i can think of.. Im lost now and It refuses to work..

 

[Joshua Parker Ruehlig]

Ok I have no clue what the hell is going on... I fixed this before but now the issue is back. Im still getting permission denied error for transmission and i have changed the user it runs as and file permissions and whatever the hell i can think of.. Im lost now and It refuses to work..

What's not working? downloading or file processing by CP/SB/SR/Sonarr.

Can you verify if the ownership/permissions of the download directory has changed.

Code:

ls -l /path/to/downloads

 

[ovizii]

###edit###
nevermind, I've started from scratch and working on it

 

[blahhumbug]

My apologizes for necroing a slightly older thread. I'm having some similar issues to CraftyClown with mylar. In particular, I see the same filecopy error occur when copying coverart from the mylar cache to the newly created directory.

But mylar is throwing this permissions related error..

2015-03-05 01:00:17ERRORUncaught exception: Traceback (most recent call last):
File "/usr/pbi/mylar-amd64/share/mylar/mylar/mylar/logger.py", line 159, in new_run
old_run(*args, **kwargs)
File "/usr/pbi/mylar-amd64/lib/python2.7/threading.py", line 763, in run
self.__target(*self.__args, **self.__kwargs)
File "/usr/pbi/mylar-amd64/share/mylar/mylar/mylar/importer.py", line 446, in addComictoDB
shutil.copy(coverfile,comiclocal)
File "/usr/pbi/mylar-amd64/lib/python2.7/shutil.py", line 120, in copy
copymode(src, dst)
File "/usr/pbi/mylar-amd64/lib/python2.7/shutil.py", line 91, in copymode
os.chmod(dst, mode)
OSError: [Errno 1] Operation not permitted: '/Comics/Supreme Blue Rose (2014)/cover.jpg'

I dug into this a fair amount and found that it's not the copy of the file that is failing, but the copy of the mode bits. The original jpg file that mylar creates in its cache directory has mode 0666, and when I look at the file in the destination mount that gets created during the initial copyfile(src, dst) call it looks like this:

-rwxrwxr-x+ 1 jason jason 48157 May 21 21:09 cover.jpg

I'm not too familiar with the +symbol at the end of the attributes, but from what I can gather this has to do with ACLs (probably because I have this mount area also mounted via CIFS).

Did you by chance ever resolve this mylar error? I'm wondering if anyone has a suggestions on what in the ACLs might be preventing a copy of a 0666 attribute to a jail mount.

 

[blahhumbug]

I'm making some forward progress on a 'work-around' until I can understand how ACLs are preventing the mode copies. For now I was able to add a new comic into mylar succesfully by commenting out the copymode() call at /usr/pbi/mylar-amd64/lib/python2.7/shutil.py:120

This removed the exception that CraftyClown and I have been seeing and mylar is now showing no errors in the log. I checked that the cover.jpg that gets created is accessible via windows/CIFS as well, and all the permissions seem fine on it.

 

[CraftyClown]

Hey Josh,

After a couple of months without problems, I seem to be having issues again :(

I think they may be caused by BTSync, but I'm not quite sure

Any files added to my downloads folder by BTSync, can't be accessed by Sickrage, Couch Potato etc. They complain about not having permissions. If I manually add files to the same folder, Sickrage and CP have no issues.

I did an ls -1 on the files that were having issues and they gave BTSyncs UID of 817. Is that normal?

I haven't made any permissions changes to my setup, but I did update BTSync over the weekend

Any thoughts?

 

[Joshua Parker Ruehlig]

Hey Josh,

After a couple of months without problems, I seem to be having issues again :(

I think they may be caused by BTSync, but I'm not quite sure

Any files added to my downloads folder by BTSync, can't be accessed by Sickrage, Couch Potato etc. They complain about not having permissions. If I manually add files to the same folder, Sickrage and CP have no issues.

I did an ls -1 on the files that were having issues and they gave BTSyncs UID of 817. Is that normal?

I haven't made any permissions changes to my setup, but I did update BTSync over the weekend

Any thoughts?

what alternative did you originally use to allow your media plugins to write to those files?
alternative 4 won't work unless you can tell btsync to write files with specific permission levels.

 

[CraftyClown]

I had so many issues getting things working a few months ago (CIFS was the bane of my life!) that I don't recall which of the 4 options worked for me in the end, although I'm pretty sure I tried all of them ;)

In theory option 2 should should be safe bet though, yes?

So if I was to say:

(presuming my main user is RICH his UID is 816 and he belongs to the group MEDIA)

1. pw useradd -n RICH -u 816 -d /nonexistent -s /usr/sbin/nologin

followed by:

1. service BTSync onestop
2. chown -R RICH:MEDIA /var/db/BTSync
3. sysrc 'BTSync_user=RICH'
4. service BTSync start

I hope I'm not getting this confused again! lol

 

[CraftyClown]

:(

So it's not gone to plan.

I tried to follow option 2, however the group 'MEDIA' was not allowed. The only thing that would work was 'wheel'

when I reached the final step and tried to restart btsync, it complains about not being able to open the pid file

What have I done wrong?



root@btsync_3:/ # chown -R RICH:wheel /var/db/btsync
root@btsync_3:/ # sysrc 'btsync_user=RICH'
btsync_user: -> RICH
root@btsync_3:/ # service btsync start
Starting btsync.
Can't open pid file /var/run/btsync/btsync.pid. Permission denied/usr/local/etc/
rc.d/btsync: WARNING: failed to start btsync
root@btsync_3:/ #

 

[Joshua Parker Ruehlig]

@CraftyClown
the jail has know idea about the MEDIA group on the freenas host. Groups aren't important if using alternative 2 so let's not worry about it for now.

As for the pidfile issue, that's a detail I left out of the instructions because it depends on the program. Deleting its directory will solve that issue (it will just be recreated when the program is started).
You will also want to change the ownership of any existing files btsync wrote previously

Code:

rm -r /var/run/btsync
chown -R RICH /path/to/mounted/dataset

 

[CraftyClown]

Thanks Josh,

so in a nutshell, BTSync won't recognise any groups I have created, only pre-existing groups, but it's not a problem because in this scenario it's not relevant. Therefore any working group I use will suffice?

Does it make sense to change the user on all my plugins? Or are there any you would advise against. I'm currently using BTSync/Plex/Sickrage/Headphones/Couchpotato/and finally Mylar

 

[Joshua Parker Ruehlig]

Thanks Josh,

so in a nutshell, BTSync won't recognise any groups I have created, only pre-existing groups, but it's not a problem because in this scenario it's not relevant. Therefore any working group I use will suffice?

Does it make sense to change the user on all my plugins? Or are there any you would advise against. I'm currently using BTSync/Plex/Sickrage/Headphones/Couchpotato/and finally Mylar

it makes sense to change the btsync user. sickrage+headphones+couchpotato+mylar already use UID 816 so there's nothing to change there.
for plex you probably don't need to change anything unless plex needs write access to your files.

 

[CraftyClown]

Cheers Josh,

I have a much simpler set up now, with only one large pool in raidz2, so fingers crossed now I've got permissions sorted for btsync, things should go a lot smoother... Famous last words ;)

 

[Supa]

So yeah I'm curious about

• chown -R USER:GROUP/var/db/PLUGIN

When I look in /var/db under the transmission jail there is no transmission file/folder.

Still got it working without using that command but yeah.

 

[Joshua Parker Ruehlig]

So yeah I'm curious about

• chown -R USER:GROUP/var/db/PLUGIN

When I look in /var/db under the transmission jail there is no transmission file/folder.

Still got it working without using that command but yeah.

If you installed transmission more than a few days ago transmission's datadirectory is actually /usr/pbi/tranmission-amd64/etc/transmission/home
I changed it this weekend to match the other plugins at /var/db/transmission

Also, like you noticed this is unnecessary for transmission, because it fixes it's own permissions during its startup script.

 

[Supa]

I'm guessing the sickrage plugin's datadirectory isn't there either? I just noticed that we could directly install that plugin now.

 

[Joshua Parker Ruehlig]

I'm guessing the sickrage plugin's datadirectory isn't there either? I just noticed that we could directly install that plugin now.

The OP has the info on sickrage. Yes it's now available directly

 

[Supa]

I don't see anything in the OP about sickrage. Should we be updating from the git or from freenas? I know before I used this:

chown -R media:media /usr/pbi/sickbeard-amd64/share/sickbeard/*

To be able to update from the git.