Container does not work out-of-the box in Windows docker

[elbosso]

There exists a problem when one tries to use this container with docker for windows: Because the "operating system" Microsoft Windows has a data dump where real operating systems have their file systems, Microsoft Windows also does not have proper user and group rights. Therefore, all files mountes as volumes have privileges 755 from within the (Linux-) container and therefore - SSH refuses to work because the file protection is too weak.

My proposal is not to change anything on the container side of things - it is merely to augment the documentation a bit for all the poor souls out there who are tasked with using docker for Windows.

If the proposal is accepted, I would write such an addendum and do a pull request. We can even go so far as to assign this issue to me...

[pierrefevrier]

Hi elboss,

I can't make bind working with Windows 10 with the following kind of args:

docker run --name client-sftp-orion ^
	-p 2222:22 ^
	-v C:\Users\myuser\sftp\root-folder:/root-folder/ ^
	-d atmoz/sftp james:bond:1001

Does it work for you ?

Any one can help ?

[elbosso]

Hello Pierre,

as i wrote in the comments section - i had some problems with the privileges when i ran the container in docker for windows. What exactly do you mean by "bind" - does the container start without errors and you cant establish a connection? or is the port not open (what does netstat -atn display - is it showing an open port 2222? Do you see any output from the container in the console - errors or otherwise?

One of my problems was with the privileges of the users folders on a windows harddisk - that i circumvented by not directly mapping the folders but mapping their root - in your example that would mean to run docker like so:

docker run --name client-sftp-orion ^ -p 2222:22 ^ -v C:\Users\myuser:/root-folder/ ^ -d atmoz/sftp james:bond:1001

Another thing is the mounting of a private/certificate pair into the container - because of the aforementioned privilege issue, ssh does not use those - i circumvented this issue by not directly mounting then to their destination but by mounting them into a temporary location and writing a script that moved them inside the container from the temporary location to their final destination. But i see that you do not use a custom key/certificate pair - so that should not be an issue

A third thing: It seems to me that you try to make the folder /root-folder/ accessible via sftp. I am pretty sure that atmoz/sftp does not work that way - normally, it exposes folders below the authenticated users home folder via sftp - in your case that would mean that the volume spec is wrong and should read somewaht along the lines of

docker run --name client-sftp-orion ^ -p 2222:22 ^ -v C:\Users\myuser:/home/james/root-folder/ ^ -d atmoz/sftp james:bond:1001

I hope, I could give you at least some ideas where to look further.

Best regards,

Juergen Key

[pierrefevrier]

Hi elbosso,
Sorry for this delay...

Container is starting without errors and I can connect to.

Thanks for your help, I'm now able to read/write files from Windows filesystem via the following docker run command:

docker run --name client-sftp-orion ^
-p 2222:22 ^
-v C:\Users\myuser\sftp\root-folder:/home/james/root-folder/ ^
-d atmoz/sftp james:bond:1001

Pierre.

[LeonT-A]

Pretty new to sftp\ssh, but I ran into a permissions issue when trying to use a custom ssh host key. Every time you run a container, a new key is generated, so all my clients would get warnings. I created one according to the README, but when I would build the sftp container using it, the logs reported that the ssh host file had permissions that were too weak and it refused to use the key I created.

What I ended up doing was kinda brutish, but it worked; I mounted the directory where the container generates new ssh host keys, built the container, and then once the keys were created I shut the container down. Because I had that directory mounted, the ssh host keys it created remained. I then moved them to my preferred location, removed the mount to the folder, and then mounted the ssh host keys directly according to the README. They got the same permissions as the ones I created (according to GitBash) but they work!