[RTFACT-13928] Artifactory run with local directory volume in Docker for Windows fails to initialize due to directory permissions Created: 18/Mar/17  Updated: 31/May/19

Status: Open
Project: Artifactory Binary Repository
Component/s: Docker
Affects Version/s: 5.1.3
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Nathan Williams Assignee: Unassigned
Resolution: Unresolved Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Docker for Windows


Support Tickets:

Schlumberger Tech Corp - Support Case, Schlumberger Tech Corp - Support Case

Product Comments: 31-May-2019: Support, please follow-up with Or Gat who's responsible for the different installers.
Support Comments: Issue is documented at:
https://www.jfrog.com/confluence/display/RTF/Installing+with+Docker#InstallingwithDocker-DockerforWindowslimitation

However, it is old and the /etc/ folder is very important to mount for data consistency.
FYI customer is using Artifactory on Docker on windows for production

 Description   
docker run -d --name jfrog-artifactory-oss-latest -p 8081:8081 -v C:/path/to/data:/var/opt/jfrog/artifactory docker.bintray.io/jfrog/artifactory-oss:latest

This produced an error at startup.

2017-03-17 19:46:41,601 [art-init] [ERROR] (o.a.w.s.ArtifactoryContextConfigListener:94) - Application could not be initialized: The folder containing the key file /opt/jfrog/artifactory/etc/security/access/keys has too broad permissions!
Please limit access to the Artifactory user only!

Creating a named volume and having Artifactory mount against the file system in the MobyLinux VM that Docker for Windows provides worked since it was able to create the specific permissions Artifactory is evidently checking for. I don't know if there's a way on Windows to configure the data directory in a way that would cause whatever check Artifactory is doing to succeed. (I tried to download the OSS source bundle and figure out where this was and had no luck whatsoever...the documentation for this appears to be out of date or incomplete.)

It's not a major issue, but it should be noted as a risk for people who want to experiment with Artifactory on Windows. This is super easy to do with Docker, but folks who decide to try to mount the data externally (whether for learning what's there or just having an easy way to back it up) will be blocked. I wanted to make sure you were aware of the limitation.



 Comments   
Comment by benjamin Mack [ 27/Feb/18 ]

aggree with nathan.
a workarround for windows (ugly but for learning or evaluation, developing plugins) simply mount more granular e.g

  • ./artifactory/access:/var/opt/jfrog/artifactory/access
  • ./artifactory/backup:/var/opt/jfrog/artifactory/backup
  • ./artifactory/data:/var/opt/jfrog/artifactory/data
  • ./artifactory/etc/plugins:/var/opt/jfrog/artifactory/etc/plugins
  • ./artifactory/logs:/var/opt/jfrog/artifactory/logs

-> do not mount ./etc/security
then it will start on docker on windows also without using a named volume

Comment by Eldad Assis [ 20/Sep/18 ]

When resolved, need to update Wiki and remove https://www.jfrog.com/confluence/display/RTF/Installing+with+Docker#InstallingwithDocker-DockerforWindowslimitation

 

Comment by Ariel Kabov [ 16/Oct/18 ]

The workaround mentioned above is not enough for Artifactory 5.7 and above, due to the requirement of providing the $ARTIFACTORY_HOME/etc/security/master.key in order to validate the correct server is connecting to the DB.

A possible workaround to versions 5.7 and above is in addition to all of the above, to also provide and mount the $ARTIFACTORY_HOME/etc/security/master.key file, as it must be persistent.

Generated at Sun Dec 15 08:56:46 UTC 2019 using JIRA 7.6.16#76018-sha1:9ed376192612a49536ac834c64177a0fed6290f5.