[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

Docker for Windows

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.

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 Tue Jul 07 09:44:49 UTC 2020 using Jira 8.5.3#805003-sha1:b4933e02eaff29a49114274fe59e1f99d9d963d7.