I’m being prompted to log in after that screen command – any thoughts?
I’ve uploaded my logs, bugsnag id is: 4D76F500-A6CA-45D2-B18A-ABFFBF17071E
Share and learn in the Docker community.
I’m being prompted to log in after that screen command – any thoughts?
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.
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!
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!!!