I'm actually not sure what the default permissions for docker are meant to be.  But I 'think' they're meant to be groups set to nobody.users.  Many dockers are being created root.root and I'm having weird things happen even if I try changing to nobody.users.

 

For example downloading the official wordpress docker, creates a root.root permissions.  If I add PUID / PGID variables into the docker, again it remains at root.root (even after deleting the wordpress appdata folder and starting from scratch).

 

Further, the below line occurs in the docker log at each start and never actually writes anything into the html folder, though it DOES create the folder. 

 

"WordPress not found in /var/www/html - copying now...
Complete! WordPress has been successfully copied to /var/www/html"

 

I've changed the folder permissions and set to 777 and still the same issue.  If I go into the docker container itself, e.g. docker exec -it wordpress - the html folder IS populated there - it's just not writing it to the config directory, which is set correctly and is shown by the folder name html showing up within the wordpress docker appdata folder.

 

I had thought this issue was limited to one container, however it is also occurring in Tdarr.

 

Is there some kind of setting I need to add I'm not aware of?  Is there some rule for the template developers need to be aware of to stop this?

 

Many thanks,

 

Marshalleq

Edited October 27, 20196 yr by Marshalleq

Start here:

      https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-680-rc1-available-r631/?tab=comments#comment-5651

and it continues here:

      https://forums.unraid.net/bug-reports/prereleases/unraid-os-version-680-rc1-available-r631/page/2/?tab=comments#comment-5669

 

I ended up changing both PUID and PGID to '0'  (basically-- root) So that I could see the flash drive using Krusader.  I  have the feeling that many other Dockers are going to require similar changes to be able to deal with the new security changes.  I read somewhere that these variables for Dockers should be set to 100/99 to prevent them from having root access but when you lose current functionality, you have to make a choice.  Details here for Krusader:

 

     https://forums.unraid.net/topic/71764-support-binhex-krusader/page/17/?tab=comments#comment-780475

 

The security changes should only affect containers that want to access files on the flash drive and I would not have thought there should be many where this is likely to be the case?

Since I haven't explained above, until about a week ago, I was running my dockers on an SSD, used by unassigned devices.  I have recently migrated this setup to ZFS, which as expected has the same issues.  I was having the issues on both configurations though.  I think there's been funny business since the 6.7 series to be honest - but it's hard to tell as I didn't add any new containers during that time and I'd really rather not go back.  @Frank1940thanks for the links - reading now!

OK I've now read those - I don't see most of that applying except it did get me thinking about permissions again.  Maybe something in the new security changes is being applied to docker files (wild and probably unlikely guess).  Further if we set up dockers as root.root, that's going to be challenging for dockers that need to write files as a non-root account because how do you tell it to do that only for e.g. media folders, but not for appdata data?

 

The way I used to get round this was to write to a share and have the share set to write as an explicit user with explicit permissions.  (Written up in a three year old post of mine here).  However, that would then require shares instead of direct mounts for files which is kinda horrible to be honest.

 

But before all of that, I need to know if I should be running dockers as root now or not.  The ones I've tried ARE being created as root - so maybe I should try living with it like that and see where it leads me.

As far as I know there should be no changes to the permissions required for dockers except perhaps in the special case of those that want to directly access the flash drive.   I have certainly not seen any of mine starting to have permission issues.