Cifs mount argument rfc, add noserverino

[Sebas-]

Expected behavior

A php application inside a i386 container should be able to recognize directories when using calls like 'stat' and 'is_dir' on mounted volumes.

Actual behavior

'stat' and 'is_dir' return false when executing the command on a mount volume path.

Information

The following stackoverflow post explains the issue:
http://stackoverflow.com/questions/26718203/php-file-directory-stat-related-functions-do-not-work-on-mounted-cifs

I have now created a remount tool (simple console app) as a temporary solution, that unmounts, and mounts the drives again with the added mount option.
In the method "CifsOptions" (Cifs.cs), I have added stringList.Add("noserverino"); just before the return string join.
Then simply do the same thing the app does, load settings, retrieve credentials, loop the SharedDrives setting, and umount+mount the drive.

I don't think it does any harm if the option is added in the application, but I could be wrong.

Perhaps it would be nice to make this part of some sort of advanced options?

If the option can not be added, and the advanced option thing is also not possible I have to wait until Docker for windows gets a proper source release, patching the dll's just for this seems overkill to me :)

Steps to reproduce the behavior

Host system: Windows 10 Pro x64 (issue is probably only on x64 systems, not sure)

Create a docker container based on 32bit/debian
Install PHP (5.3)
Run the container and mount for example your c drive to /mnt
in the container, execute this bit of code:

[rn]

@Sebas- Thanks for the report.

This works fine with the default php images:

PS C:\WINDOWS\system32> cat C:\Users\rneugeba\AppData\Local\bar\foo.php
<?php var_dump(is_dir("/mnt"));
PS C:\WINDOWS\system32> docker run --rm -ti -v C:\Users\rneugeba\AppData\Local\bar:/mnt php php /mnt/foo.php
bool(true)

and also with 32bit debian:

docker run --rm -ti -v C:\Users\rneugeba\AppData\Local\bar:/mnt 32bit/debian /bin/bash
root@e755a04a798f:/# apt-get update
root@e755a04a798f:/# apt-get install -y php5
root@e755a04a798f:/# php /mnt/foo.php
bool(true)

[Sebas-]

Thanks for the response.

Looks like i've got an interesting issue then. The php version in your test is 5.6 and 7 so those are not the same, but when I added the official debian php 5.3 build (from debian 7), it did not show the issue.

My container has a manually compiled version (on the 32bit/debian container) build, and that one does show the issue (.

I'm a little bit puzzled to why that is. As far as I can tell it should work, but it looks like debian patched their php5.3 build with something that fixes this issue.

root@998a944bd42c:~/php/# wget http://nl1.php.net/get/php-5.3.29.tar.gz/from/this/mirror -O php-5.3.29.tar.gz
root@998a944bd42c:~/php/# tar xvf php-5.3.29.tar.gz
root@998a944bd42c:~/php/# cd php-5.3.29
root@998a944bd42c:~/php/php-5.3.29# ./configure
root@998a944bd42c:~/php/php-5.3.29# make
root@998a944bd42c:~/php/php-5.3.29# ./sapi/cli/php /mnt/test.php

Fatal error: Unknown: Failed opening required '/mnt/test.php' (include_path='.:/usr/local/lib/php') in Unknown on line 0
root@998a944bd42c:~/php/php-5.3.29/sapi/cli# stat /mnt/test.php
  File: '/mnt/test.php'
  Size: 42              Blocks: 1          IO Block: 16384  regular file
Device: 29h/41d Inode: 1407374883767242  Links: 1
Access: (0755/-rwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2016-08-01 16:56:43.557068400 +0000
Modify: 2016-08-01 16:56:43.557068400 +0000
Change: 2016-08-01 16:56:43.557068400 +0000
 Birth: -
root@998a944bd42c:~/php/php-5.3.29/sapi/cli#
root@998a944bd42c:~/php/php-5.3.29/sapi/cli# cat /mnt/test.php
<?php
var_dump(is_dir("/mnt/testdir"));
root@998a944bd42c:~/php/php-5.3.29/sapi/cli# ls /mnt/
test.php  testdir

(docker run 32bit/debian with volume mount test directory to /mnt)

Since my added mount option fixes the problem for me right now, and my team can work with this, there is no hurry to find the reason (have to do some real work ;) ).

My feature request still stands, adding the mount option, or even creating an advanced option so users can set their own (though I can imagine you might not want this).

As long as de Docker for Windows keeps working the way it does I'm happy, and when I finally gets open sourced and I still have this issue I'll just patch that version and let everybody that needs it install the patched version :)

Sebas

[rn]

Thanks. we are looking into the suggested CIFS mount option

[rn]

@Sebas- we took another look at the option and it looks like it might break hardlinks semantics (e.g: http://www.spinics.net/lists/linux-cifs/msg10477.html). Since your example seem to work with some standard 32bit images (like PHP on 32bit debian) and you ahve a work-around. I'm closing this issue.

Thanks, for the issue report and the nice and simple repro. It made it very easy to test for us.

[Sebas-]

Oke, thanks for info.

[ccouton]

Hi, is it possible to have your workaround?

[Sebas-]

@cedseat sure, but keep in mind this is not officially supported in any way or form :)

https://github.com/ambrero/docker-remount/releases

[Sebas-]

@cedseat you can verify if the remounting works like this:

``

docker run -it --rm -v/var/log:/mnt alpine /bin/ash
/ # tail -f /mnt/messages
Aug 8 12:45:44 moby kern.info kernel: docker0: port 2(veth05615c9) entered forwarding state
Aug 8 12:45:45 moby user.info KVP: umount: /C and /c
Aug 8 12:45:45 moby user.info KVP: mount: cifs //10.0.75.1/C to /C and /c
Aug 8 12:45:46 moby user.info KVP: umount: /D and /d
Aug 8 12:45:46 moby user.info KVP: mount: cifs //10.0.75.1/D to /D and /d
``

The remount tool might need a "Run as administrator" on some windows installations.

[ccouton]

Thanks! Where did you found the *.cs source codes?

[Sebas-]

Nowhere, look at the top of the cs files.

Just lucky that the application is so well set up (code wise), they are doing a good job with it, and I believe that it will be sourced eventually.

[ccouton]

Excellent 😉

[justincormack]

@sebas it will work if you compile with -DLARGEFILE_SOURCE _FILE_OFFSET_BITS=64 this is how Debian compiles everything which is why it works.

[friism]

@cedseat what problem are you encountering with the default mount options? Is it also related to custom-build PHP, or something else?

[Sebas-]

@justincormack Looks like that works, updating the app container tomorrow, thanks!
I would probably not have figured that one out within the time I have :)

[ccouton]

The problem is here : moby/moby#24837
@sebas why do you delete your github repo? https://github.com/ambrero/docker-remount/releases

[Sebas-]

@cedseat request by docker, github/docker does not allow decompiled code to be put in a public repository.

assuming you made local checkout or downloaded the zip?

[mattvonarx]

@Sebas- This is still an active issue for me, are you able to PM or email the source?

[Sebas-]

@VectorAlpha sorry for the late reply, but just take a dotnet decompiler (dotpeek) and recompile it yourself (hoping they have not put an obfuscator over the current compile since docker for windows is clearly not meant to be open source since it's still not published).

[docker-robott]

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