Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

G:\ workaround no longer working in nano (no longer admin) - ES image #6

Open
marcanpilami opened this issue Dec 29, 2017 · 1 comment

Comments

@marcanpilami
Copy link

Hi,

in the latest versions of nano, such as microsoft/nanoserver:1709 and Microsoft/powershell:nanoserver the account used by Docker is no longer admin. So it is not possible to modify HKLM anymore, and therefore not possible to create the G: alias.

My attempts are with the ElasticSearch image (my actual goal is to create a 1709 image of Nexus, which uses Elasticsearch, so I start with your dockerfile - but in all cases, your dockerfile will no longer work as soon as the OpenJDK project updates its nano image).

I have tried to map the G: drive in the the Dockerfile (VOLUME G:) - it actually works, but ES still exploses on sun.nio.fs.WindowsLinkSupport.getFinalPath as was the case before your hack came up. So I guess it is not a "true" fixed drive - [System.IO.DriveInfo]::getdrives() reports it as a network drive, which is quite surprising.

I have also tried to find a non-admin way of creating the alias, to no avail (no corresponding key in HKCU, no subst command in nano that could be run on each startup...). Also, haven't tried, copy subst.exe into the image and run it before the start command... would be a license issue anyway.

The only way I currently see is to docker exec into the image, make the change and commit to create an image from the container... (docker container exec -i -t -u ContainerAdministrator xxxxx cmd /C REG ADD "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\DOS Devices" /v "G:" /t REG_SZ /d '\??\C:\data') Truly ugly, but it works OK. I'm however looking for a pure Dockerfile solution.

Would you have a workaround for the workaround?

Thanks,
Marc

@richardgavel
Copy link

If you use 1803 instead, the mounts no longer appear as shortcuts, but as normal directories, making the G: alias unncessary

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants