Unable to access volumes using osxfs ("/Mac: Socket not connected") - [f]stat[v]fs family of functions

I’m being prompted to log in after that screen command – any thoughts?

Login Prompt

I’ve uploaded my logs, bugsnag id is: 4D76F500-A6CA-45D2-B18A-ABFFBF17071E

Username: root
No password

Thanks!

docker:~# cat /var/transfused_start.log
2016-03-29 20:12:11.250 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac
2016-03-29 20:12:11.251 Log mount trigger fired on /Mac, logging to /Mac/Users/tom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-03-30 17:44:08.199 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac
2016-03-30 17:44:08.203 Log mount trigger fired on /Mac, logging to /Mac/Users/tom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-03-30 17:46:28.981 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac
2016-03-30 17:46:28.984 Log mount trigger fired on /Mac, logging to /Mac/Users/tom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-03-31 17:57:05.508 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac
2016-03-31 17:57:05.510 Log mount trigger fired on /Mac, logging to /Mac/Users/tom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-06 03:29:32.342 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac
2016-04-06 03:29:32.344 Log mount trigger fired on /Mac, logging to /Mac/Users/tom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log

Providing my info as well:

~ pinata diagnose -u
OS X: version 10.11.4 (build: 15E64a)
Docker.app: version v1.11.0-beta6
Running diagnostic tests:
[OK]      docker-cli
[OK]      Moby booted
[OK]      driver.amd64-linux
[OK]      vmnetd
[OK]      osxfs
[OK]      db
[OK]      slirp
[OK]      menubar
[OK]      environment
[OK]      Docker
[OK]      VT-x
Docker logs are being collected into /tmp/20160406-123425.tar.gz.
Your unique id in bugsnag is: D42DC90E-3BCE-4C61-93A6-C271A46292A6
docker:~# cat /var/transfused_start.log
2016-04-02 05:01:43.976 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-02 05:01:43.977 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-02 05:30:37.845 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-02 05:30:37.847 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-02 05:38:27.694 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-02 05:38:27.695 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-02 05:39:13.600 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-02 05:39:13.601 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-02 06:49:16.113 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-02 06:49:16.115 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-02 06:49:40.636 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-02 06:49:40.638 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-03 18:24:40.633 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-03 18:24:40.635 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-06 16:10:00.696 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-06 16:10:00.698 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-06 16:11:13.669 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-06 16:11:13.670 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-06 19:01:15.693 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-06 19:01:15.695 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log
2016-04-06 19:17:12.613 mount /bin/fusermount -o allow_other,max_read=32741,subtype=osxfs /Mac 
2016-04-06 19:17:12.615 Log mount trigger fired on /Mac, logging to /Mac/Users/cliffom/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/log/transfused.log

The /Mac mount point exists on the VM:

docker:~# mount | grep Mac
osxfs on /Mac type fuse.osxfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=32741)

I can mount a folder on my Mac’s / via

docker run --rm -it -v /Mac/var:/tmp/test -w /tmp/test alpine /bin/sh

It appears fuse.osxfs is working as intended:

/tmp/test # mount |grep test
osxfs on /tmp/test type fuse.osxfs (rw,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other,max_read=32741)

@tomfrost Would you mind confirming whether or not this is the case on your end?

Can anyone comment on how to get more info on the “Socket not connected” message?

@cliffom I have the same results to all your tests on my machine. Good catch! So osxfs is there, it’s just not automounting. What’s more, this confirms that the test from the file access performance thread was, in fact, running over osxfs; and so that’s where the speed issue is.

@ddunbar df for me reports “Function not implemented” for my osxfs mounts.

@tomfrost I don’t think auto-mounting /Mac to containers is intended behavior. Containers only mount volumes passed explicitly with -v; Having /Mac in the VM allows you to mount directories outside of /Users and in the Mac volume root / by prefixing them with /Mac. At least that is my understanding.

Perhaps @dsheets can chime in and set us straight. However, as it stands, I don’t think we are having the issues @ddunbar is experiencing.

1 Like

That was my understanding as well.

@ddunbar Socket not connected is concerning to me – it indicates that the VM-side component of osxfs is not running. Can you reproduce it? Does it occur on start-up or only after running a container? Always after running a single container? Do you have a core file in / or /var?

@cliffom I believe your understanding is correct. We are still developing the appropriate bind mount semantics but, in Beta 6, the special host paths available for bind mounts are /Mac (the whole host), /Users, /Volumes, /tmp, and /private. The mount points only appear in containers when using -v to bind mount into the mount namespace of the container. This gives containers and their operators complete control over the file system namespace of the containerized software.

Unless other people are experiencing Socket not connected or Transport endpoint not connected errors, a new thread should be created to discuss other issues with osxfs.

@tomfrost The [f]stat[v]fs family of functions (which are necessary for proper df function) are not yet implemented. We have support planned which will export the entire mount table of OS X into the VM but it hasn’t been completed yet. This may also cause issues with database software that expects to be able to successfully execute these syscalls against its data store. Watch the changelog for updates regarding this feature and thanks for using Docker for Mac Beta!

@ddunbar What is the location and content of your home directory symlink?

The link is:

$ ls -lP /Users/ddunbar
lrwxr-xr-x  1 ddunbar  admin  21 Jun 29  2015 /Users/ddunbar -> /Volumes/Data/ddunbar

and /Volumes/Data is an otherwise normal volume (it does use full disk encryption, if that could be related at all).

Does the exact symlink matter if I am completely unable to see any of the mounts inside the VM, or is there some other magic going on when -v is used?

I thought this was fixed in the latest beta, but didn’t look closely enough. What has changed is that I now see the directories in the container, but they don’t have any actual files in them.

Hi Daniel,

Could you please try this again with Beta 8? If it still doesn’t work for you, posting the unique ID from pinata diagnose -u would be helpful as Beta 8 has both better file sharing robustness and better logging to help us track down this issue.

Thank you!

@dsheets trying to follow along with this issue. Are you saying that the df command should now work in beta9? or was that referring to some other command in this thread?

df will return Function not implemented for shared directory mountpoints in beta9.

Fixed in beta 9. Thanks!!!

1 Like