chown has no affect for mounted volumes about for-win HOT 48 CLOSED

This is an important feature we need Docker and Microsoft working at it ASAP. How can 13 other million developers embrace containers seriously if they cannot mount volumes successfully and easily? Thanks

from for-win.

I'm sorry, but closing this as "won't fix" at least not on SMB/CIFS. LCOW currently also does not support chown but may in the future...it's under active development.

from for-win.

Still persists :'(

from for-win.

Any update on this blocker?

from for-win.

and with the drvfs ?

https://blogs.msdn.microsoft.com/commandline/tag/drvfs/

https://www.youtube.com/watch?v=PHlLsSsJxyA

from for-win.

What you are trying to achieve: Running a native linux database with a native linux container platform in a native environment emulated in a vm and then mount that thing non natively on a totally different file system which does not support features the native linux programs expect to be there and the tools just fake to make it somehow work.

I am sorry but you are just trying to do a thing which is not possible right now and instead of searching for a working solution or contributing one you are whining here that it does not work.

What you can do:

• use linux
• use a linux vm
• don't mount that thing at all and manage it solely with postgres tools and backup a dump
• use a db over the network on a linux server.
• use wsl in the native file directory area
• use posgres for windows
• use posgtres for windows in a native container docker-library/postgres#324

and to answer your questions:

Why do you consider the problem small and developers affected as few?

There are millions of docker users and like a hundred here complain about a thing. Thats not much to be honest.

Note, then this and related issues are active for several years.

Many significant software bugs are open forever and eventually fixed or the software is replaced.

Note also, that over half of the developers work on Windows according to this SO survey.

First of all this is wrong. Half of the devs that took that survey use windows. Linux user are usually more privacy focused at least in my experience and maybe a lot of them just did not take the survey.

Also we don't know how many of those windows users use containers. The percentage could be 1.4% or 46.1%. My quick look at the statistic didn't provide that info but most likely somewhere in between is the right answer.

And my best advice for non working software is: Expand and build your own piece of code that fits your requirments or change your requirements.

from for-win.

Currently, a workaround for this is to use named volumes. It's not exactly the same, but gets the job done:

https://forums.docker.com/t/data-directory-var-lib-postgresql-data-pgdata-has-wrong-ownership/17963/25

(The link above is courtesy of this SO question: https://stackoverflow.com/questions/43504238/postgresql-docker-container-on-widnows )

from for-win.

should they fix such small problems for a few developers

Why do you consider the problem small and developers affected as few?
Note, then this and related issues are active for several years.
Note also, that over half of the developers work on Windows according to this SO survey.

from for-win.

Is there any update to this? It seems like it is more or less impossible to run certain linux containers on a windows host...

from for-win.

+1... blocker for windows. would appreciate any information on workarounds.

from for-win.

Looks related to https://forums.docker.com/t/data-directory-var-lib-postgresql-data-pgdata-has-wrong-ownership/17963.

Anyone found a way around this?

from for-win.

my god, big bug, what to do ...

from for-win.

Any update?

from for-win.

Unfortunately, with the current implementation (based on CIFS/Samba) we can't improve this.

Attempting to change these values via chmod/chown will return success but have no effect.

https://www.samba.org/samba/docs/man/manpages-3/mount.cifs.8.html#id2532725

I'm leaving this issue open for tracking.

from for-win.

Any update?

from for-win.

This behavior renders the PostgreSQL container pretty much useless on a Windows host, because it will not run as user root, and it will not run unless the user under which the process is running owns the files.

from for-win.

@ptrewhella I haven't tried it but Beta25 brings some changes to the file mounting. There's a slight chance that it might help. Could you give it a try?

from for-win.

One more to add to the list of blocked users :\

from for-win.

Is this deterrent to using Microsoft or Apple products to truly contribute linux hosted software?

No but don't expect anyone to fix your problem for you if you do that. There is a tendency in open source software that if you have a obscure problem on hardware or software I don't own that you provide a fix. Docker is big but should they fix such small problems for a few developers where a workaround is available or develop something greater everyone benefits from?

linux based

There is the problem: Linux is not Windows and translation is not always easy and could take a lot of afford. If it would be a 5 min fix someone would have already done it.

from for-win.

Isn't that the whole point of docker ?

No, docker is not a VM!
And what you are trying to do works perfectly in a VM.

might as well not have issue trackers

Even a developer which works alone on the software and does not make it public could use a bug tracker to keep track of stuff.

from for-win.

The whole point of docker is process, file system and network isolation with some extras. You can do all those things with native Linux tools and all those features are generally supported without docker but they are harder to set up and maintain and you need to know a lot of about Linux to do it right. There comes docker in, it helps you set up those isolations and maintain and update them. It does not magic smoke and it does not make VM or emulator work.

FYI everything in my docker setup would work on a native Linux machine but I would need to take care of a lot of things and I couldn't run alpine on a Debian or quickly try stuff out.

Yeah, cause you don't pay the developer and he does not owe you anything. He can be nice and fix it or he can just say that I don't really expected this program to do this and leave you with your problem alone.

from for-win.

@MatthewLymer I listed other possible solutions to this problem that are different from just deal with it.

If someone can solve the "actual problem" than go ahead and do it. I won't stop him.

BTW did anyone try this with wsl2? WSL2 sounds promising and it could mabye fix this issue.

from for-win.

What the fuck

I always knew that running docker on a windows is a big no-go, but this is bug of a top priority because it makes a development environment useless.

from for-win.

Here is a similar command executed on my Mac. Notice the owner is changed to postgres:postgres.

iridium:rt ptrewhella$ docker run --rm -v /Users/ptrewhella/data:/var/lib/postgresql/data postgres /bin/bash -c "chown postgres:postgres /var/lib/postgresql/data && ls -lh /var/lib/postgresql"

total 512 drwxr-xr-x 2 postgres postgres 68 Aug 17 00:23 data iridium:rt ptrewhella$

from for-win.

@dgageot Yes, sure I'll try it now. Thanks.

from for-win.

@dgageot Just updated and ended up with the same results (root:root) after chown.

from for-win.

I can replicate this behavior as of Docker for Windows 1.12.1-stable (b7135). I tried Chowning via docker exec, and via bash.

from for-win.

I still can replicate this behavior on 1.12.5 (9503) stable

from for-win.

Are there plans, if it's not already a thing, to be able to specify what user to mount the volume as? I see in that manpage link from above that setting uid and gid could essentially serve the same purpose as chowning.

Edit: Just realized I was re-proposing #63. Keeping comment here since that was closed prematurely

from for-win.

@glinton there's not a simple way to do that unfortunately. Host volume mounting on Windows 10 is done with a unitary mount of the whole drive so supporting different mappings for various mounts is not an option.

from for-win.

Hmm, even being able to change the uid/gid of that single mount would be quite useful to at least myself (and team). It seems like it would have to be configured elsewhere (rather than as an option to -v) as it would impact all mounts, as you mentioned. That is, if it was to be implemented at all.

from for-win.

I get the same behavior with 18.01.0-ce on Windows 10 1709 (16299.192) using LCOW.

Unfortunately, with the current implementation (based on CIFS/Samba) we can't improve this.

@friism Will it eventually improve with LCOW?

from for-win.

@johlandabee I hope so! @jstarks would have the details

from for-win.

Agreed, the only workaround I found was to install a Linux VM and run docker from there, this defeating the purpose. I should not my setup is server 1709 which requires docker-ee so a little different than the typical docker for Windows, but my testing with D4W showed the same results

from for-win.

How to workaround this issue? Can WSL help with this?

from for-win.

Currently there is no workaround. As said in the future LCOW (Linux Containers on Windows) may support chown but I have no idea about the timeframe (this is developed by Microsoft)

from for-win.

@friism @rn Just throwing this out there, and I haven't really thought this through, but wouldn't a relatively easy fix for this be simply to change docker volume create functionality to create an ext4 formatted .vhdx and mount it into the MobyLinuxVM at /var/lib/docker/volumes/<volumename>/_data? I think the same idea would probably work for Windows Container mode running Linux containers (i.e. create ext4 formatted the .vhdx under $env:ProgramData\Docker\volumes\<volumename>\_data and have the linux container mount it)

from for-win.

+1

Haven't jump the ship to docker for ages now because there are constantly issues with docker-for-win. finally decided to set up containers for my app and now this...

Sticking to vagrant I guess until somone chmods the folder

from for-win.

I run into this problem too. My windows 10 version is 1909. Wish to chown succecfully.

from for-win.

Is this deterrent to using Microsoft or Apple products to truly contribute linux hosted software? I for one would prefer to allow limited rw capability for ease of linux based micro-service development, and this seems like a true hindrance.

from for-win.

What you are trying to achieve: Running a native linux database with a native linux container platform in a native environment emulated in a vm and then mount that thing non natively on a totally different file system which does not support features the native linux programs expect to be there and the tools just fake to make it somehow work.

Isn't that the whole point of docker ? or VM for that matter? having tools in environment that natively are not supported by that env or do not exist

And my best advice for non working software is: Expand and build your own piece of code that fits your requirments or change your requirements.

This is a fair advice but then might as well not have issue trackers and put default reply "if ti doesn't work - fix it yourself".

from for-win.

@SuperSandro2000 you are cherry picking my response. Of course docker is not VM

I said is it not the whole point of docker to have

tools in environment that natively are not supported by that env or do not exist

as your argument was users are asking too much from this feature because linux and windows and it dosen't work.

Even a developer which works alone on the software and does not make it public could use a bug tracker to keep track of stuff.

Again cherry picking and missed my point. If code is public and issue tracker is public you as dev should expect repetitive comments from general public about an issue and generic complaints when something is broken. Otherwise every single open source rpoject might close the issue tracker to public as general advice YOU have is "either expand it or fix it"

from for-win.

@SuperSandro2000 I've been trying to solve this issue for quite some time now, and I see your replies on every mention of the problem. What is your motivation for telling everyone basically "just deal with it" or "switch to an operating system that supports unix permissions", is it because you actively don't want anyone to solve the actual problem?

from for-win.

@MatthewLymer I listed other possible solutions to this problem that are different from just deal with it.

If someone can solve the "actual problem" than go ahead and do it. I won't stop him.

BTW did anyone try this with wsl2? WSL2 sounds promising and it could mabye fix this issue.

I'm using WSL 2, and this problem occurs there too.

The only way I've found to make it work is to run and store everything within WSL 2, in non-windows (/mnt/) directories... But I'm not such a fan of that approach, as it's not really any different to just running everything within a VM to begin with. In fact, it's worse, as it's less documented on how to access it from Windows than simply spinning up a Vagrant box, or whatever.

from for-win.

With WSL/WSL2 you can optionally enable POSIX metadata on your Windows files. This blog entry has some good information on setting it up.

from for-win.

With WSL/WSL2 you can optionally enable POSIX metadata on your Windows files. This blog entry has some good information on setting it up.

While that's true, and it does technically work... It falls down when you create/modify a file/folder through Windows though.

The modifications outlined only affect files/directories created/modified within *nix-land.

If that's the case, then you might as well just use WSL for everything, and just store your files in there permanently.

wsl -- docker run --rm -v /var/lib/postgresql/data:/var/lib/postgresql/data postgres

Then in file explorer/cmd/whatever navigate to:

\\wsl$\Ubuntu-18.04\var\lib\postgres\data

To edit your files from within Windows (switching Ubuntu-18.04 for your default WSL distro).

from for-win.

I just ran the docker in Ubuntu's VM lol...
Any benefits from tryharding to run it on Windows?

from for-win.

Closed issues are locked after 30 days of inactivity.
This helps our team focus on active issues.

If you have found a problem that seems similar to this, please open a new issue.

Send feedback to Docker Community Slack channels #docker-for-mac or #docker-for-windows.
/lifecycle locked

from for-win.