ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
qemu-system-x86_64: warning: dbind: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-ck7sggRxK6: Connection refused
QEMU 5.1.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `dac'
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
(qemu:11): Gdk-ERROR **: 05:51:16.387: The program 'qemu' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 232 error_code 2 request_code 130 (MIT-SHM) minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
/bin/sh: line 1: 10 Done envsubst < ./Launch.sh
11 Trace/breakpoint trap (core dumped) | bash
I used to be able to successfully run Docker-OSX on an Intel Core i7-8700k on the same Ubuntu 20.04 host system (with an order Docker-OSX image version though). Is AMD somehow not supported? The error message seems to suggest this is an X Server error? But I should have X Server properly enabled on my system.
Please kindly help. Thanks in advance!
Originally created by @xJonathanLEI on GitHub (Oct 15, 2020).
Host: **Ubuntu 20.04**
CPU: **AMD Ryzen 9 3950X 16-Core Processor**
Using the latest image from Docker Hub:
$ sudo docker inspect sickcodes/docker-osx:latest
...
"Id": "sha256:3a4030001017c26e81bd0b9d8561a5889d8fbaf72dde739972fee2ad815c8df2"
...
When running this command:
sudo docker run \
--device /dev/kvm \
--device /dev/snd \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-e "DISPLAY=${DISPLAY:-:0.0}" \
--name osx \
sickcodes/docker-osx:latest
It fails with:
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
qemu-system-x86_64: warning: dbind: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-ck7sggRxK6: Connection refused
QEMU 5.1.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `dac'
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
(qemu:11): Gdk-ERROR **: 05:51:16.387: The program 'qemu' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 232 error_code 2 request_code 130 (MIT-SHM) minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
/bin/sh: line 1: 10 Done envsubst < ./Launch.sh
11 Trace/breakpoint trap (core dumped) | bash
I used to be able to successfully run Docker-OSX on an Intel Core i7-8700k on the same Ubuntu 20.04 host system (with an order Docker-OSX image version though). Is AMD somehow not supported? The error message seems to suggest this is an X Server error? But I should have X Server properly enabled on my system.
Please kindly help. Thanks in advance!
I guess it's not a CPU issue after all... I mean I can successfully install macOS following the instructions on OSX-KVM:
@xJonathanLEI commented on GitHub (Oct 15, 2020):
I guess it's not a CPU issue after all... I mean I can successfully install macOS following the instructions on [OSX-KVM](https://github.com/kholia/OSX-KVM):

Hey man! Interesting bug, first new bug I've seen in ages! I will test this shortly thank you for reporting.
@sickcodes commented on GitHub (Oct 15, 2020):
Hey man! Interesting bug, first new bug I've seen in ages! I will test this shortly thank you for reporting.
Given the message includes reference to shared memory try adding:
--shm-size=6G
And possibly try that with and without
--device /dev/shm \
Perhaps you are missing one of the above, or
gdk-pixbuf2 is the only package I have with gdk I believe
@sickcodes commented on GitHub (Oct 15, 2020):
Current image working on my AMD R9 4900H
Given the message includes reference to shared memory try adding:
` --shm-size=6G `
And possibly try that with and without
`--device /dev/shm \ `
Perhaps you are missing one of the above, or
`gdk-pixbuf2` is the only package I have with gdk I believe
Hi! Thanks for the speedy reply! Happy to help debug the issue.
Adding --shm-size=6G without --device /dev/shm \ gives the exact same log as originally posted.
Adding both --shm-size=6G and --device /dev/shm \ gives:
docker: Error response from daemon: error gathering device information while adding custom device "/dev/shm": not a device node.
ERRO[0000] error waiting for container: context canceled
@xJonathanLEI commented on GitHub (Oct 15, 2020):
Hi! Thanks for the speedy reply! Happy to help debug the issue.
Adding `--shm-size=6G` without `--device /dev/shm \` gives the exact same log as originally posted.
Adding both `--shm-size=6G` and `--device /dev/shm \` gives:
docker: Error response from daemon: error gathering device information while adding custom device "/dev/shm": not a device node.
ERRO[0000] error waiting for container: context canceled
Ahh just in case, by "the same host system" I meant the same distro with the same version (20.04 LTS), not the same installation.
@xJonathanLEI commented on GitHub (Oct 16, 2020):
Ahh just in case, by "the same host system" I meant the same distro with the same version (20.04 LTS), not the same **installation**.
SHM is a ramdisk for anyone reading this, you can see it with df and if you put files in the mountpoint, like /tmp your system stores those files in RAM.
@sickcodes commented on GitHub (Oct 16, 2020):
> Hey check out this page
>
> https://github.com/moby/moby/issues/6758 down the very bottom with tmpfs
`-v /dev/shm --tmpfs /dev/shm:rw,nosuid,nodev,exec,size=4g`
SHM is a ramdisk for anyone reading this, you can see it with `df` and if you put files in the mountpoint, like `/tmp` your system stores those files in RAM.
So I changed --device /dev/shm to -v /dev/shm and now Docker doesn't complain anymore, except qemu is again showing the same error message:
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
qemu-system-x86_64: warning: dbind: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-TOqw1i2t5S: Connection refused
QEMU 5.1.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `dac'
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
(qemu:11): Gdk-ERROR **: 08:43:21.468: The program 'qemu' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 232 error_code 2 request_code 130 (MIT-SHM) minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
/bin/sh: line 1: 10 Done envsubst < ./Launch.sh
11 Trace/breakpoint trap (core dumped) | bash
Here's the full command I'm using for running the container:
@xJonathanLEI commented on GitHub (Oct 17, 2020):
Thanks for the update!
So I changed `--device /dev/shm` to `-v /dev/shm` and now Docker doesn't complain anymore, except qemu is again showing the same error message:
ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519
qemu-system-x86_64: warning: dbind: Couldn't connect to accessibility bus: Failed to connect to socket /tmp/dbus-TOqw1i2t5S: Connection refused
QEMU 5.1.0 monitor - type 'help' for more information
(qemu) qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
qemu-system-x86_64: warning: host doesn't support requested feature: CPUID.01H:ECX.pcid [bit 17]
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dmix.c:1090:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `dac'
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
ALSA lib pcm_dsnoop.c:642:(snd_pcm_dsnoop_open) unable to open slave
alsa: Could not initialize ADC
alsa: Failed to open `default':
alsa: Reason: No such file or directory
audio: Failed to create voice `adc'
(qemu:11): Gdk-ERROR **: 08:43:21.468: The program 'qemu' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadValue (integer parameter out of range for operation)'.
(Details: serial 232 error_code 2 request_code 130 (MIT-SHM) minor_code 3)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
/bin/sh: line 1: 10 Done envsubst < ./Launch.sh
11 Trace/breakpoint trap (core dumped) | bash
Here's the full command I'm using for running the container:
sudo docker run \
--device /dev/kvm \
--device /dev/snd \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-e "DISPLAY=${DISPLAY:-:0.0}" \
--shm-size=6G \
-v /dev/shm \
--name osx \
sickcodes/docker-osx:latest
I think because you're running as sudo, sudo is a different environment, are you running your display manager as sudo too?
You should add yourself to the Docker group, or I believe there's some way to do it without root.
@sickcodes commented on GitHub (Oct 17, 2020):
I think because you're running as sudo, sudo is a different environment, are you running your display manager as sudo too?
You should add yourself to the Docker group, or I believe there's some way to do it without root.
@gruaig commented on GitHub (Oct 17, 2020):
Will give it a try but I don't believe that will be the case. Will update
shortly
On Sat 17 Oct 2020, 4:13 PM sickcodes, <notifications@github.com> wrote:
> I think because you're running as sudo, sudo is a different environment,
> are you running your display manager as sudo too?
>
> You should add yourself to the Docker group, or I believe there's some way
> to do it without root.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/sickcodes/Docker-OSX/issues/95#issuecomment-711027511>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABJS4EQRLQCVJIXWQNXCMVTSLGYBFANCNFSM4SRQMBOA>
> .
>
It seems that somehow the issue automatically went away on my machine. I'll try to find a way to reproduce it thought.
@xJonathanLEI commented on GitHub (Oct 17, 2020):
Hmmmm I didn't expect this to work, as I always used `sudo` for Docker commands and haven't had issues with Docker-OSX on my previous machine.
But somehow it works... though I seriously doubt it's the cause.
So here's what I did. I booted into the system, added myself to the Docker group, got rid of `sudo` in the command, and boom, it works.
But then I remove the container, add `sudo` back to the command, and run it again. It still works...
I even removed both `--shm-size=6G` and `-v /dev/shm` options, and it still works.
So my command is now:
sudo docker run \
--device /dev/kvm \
--device /dev/snd \
-v /tmp/.X11-unix:/tmp/.X11-unix \
-e "DISPLAY=${DISPLAY:-:0.0}" \
--name osx \
sickcodes/docker-osx:latest
and runs without issue.
It seems that somehow the issue automatically went away on my machine. I'll try to find a way to reproduce it thought.
Perhaps on previous machine, you had different groups set up
@sickcodes commented on GitHub (Oct 17, 2020):
It's probably a combination of
-Docker group
-Running as sudo
-Your desktop isn't sudo (normal)
-We are using X11 forwarding into the user env
Perhaps on previous machine, you had different groups set up
Hmm both machines are (almost) clean installations of Ubuntu 20.04 with no changes on user/group.
But if that's actually the cause, why am I not seeing the issue again after I:
Remove myself from docker group
Reboot
Create container as root
I'm now using the command I started with.. That's weird. I should have tested if it works right before adding my user to docker group..
@xJonathanLEI commented on GitHub (Oct 17, 2020):
Hmm both machines are (almost) clean installations of Ubuntu 20.04 with no changes on user/group.
But if that's actually the cause, why am I not seeing the issue again after I:
- Remove myself from docker group
- Reboot
- Create container as root
I'm now using the command I started with.. That's weird. I should have tested if it works right before adding my user to docker group..
@sickcodes commented on GitHub (Oct 17, 2020):
https://github.com/sickcodes/Docker-OSX/commit/07f488a470bf4f04f03b369d87e1c05b3706397d#L148
Could be related to this change made not long ago
@BackMountainDevil commented on GitHub (Jul 2, 2021):
Will give it a try but I don't believe that will be the case. Will update shortly …
On Sat 17 Oct 2020, 4:13 PM sickcodes, @.***> wrote: I think because you're running as sudo, sudo is a different environment, are you running your display manager as sudo too? You should add yourself to the Docker group, or I believe there's some way to do it without root. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#95 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABJS4EQRLQCVJIXWQNXCMVTSLGYBFANCNFSM4SRQMBOA .
Hi, I wonder how you achieve the markdown gammar. I copy your reply md code to vscode to preview. it will not be folded...
@BackMountainDevil commented on GitHub (Jul 2, 2021):
> Will give it a try but I don't believe that will be the case. Will update shortly
> […](#)
> On Sat 17 Oct 2020, 4:13 PM sickcodes, ***@***.***> wrote: I think because you're running as sudo, sudo is a different environment, are you running your display manager as sudo too? You should add yourself to the Docker group, or I believe there's some way to do it without root. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <[#95 (comment)](https://github.com/sickcodes/Docker-OSX/issues/95#issuecomment-711027511)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJS4EQRLQCVJIXWQNXCMVTSLGYBFANCNFSM4SRQMBOA> .
Hi, I wonder how you achieve the markdown gammar. I copy your reply md code to vscode to preview. it will not be folded...
I've been facing the same issue if I'm not mistaken:
(qemu:1158): Gdk-WARNING **: 19:46:15.151: The program 'qemu' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
(Details: serial 225 error_code 10 request_code 130 (MIT-SHM) minor_code 1)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
It's not the first time getting this error but it used to get fixed randomly, not sure how or why. I've also tried to run xhost + mentioned in #115 but nothing changes.
Is there anything I can do to debug the issue? I've tried multiple potential solutions from this thread but it didn't make any difference.
I'm on archlinux using the latest image available (it also happens with ventura, I haven't tested older images).
@JetpackDuba commented on GitHub (Dec 12, 2024):
I've been facing the same issue if I'm not mistaken:
```
(qemu:1158): Gdk-WARNING **: 19:46:15.151: The program 'qemu' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAccess (attempt to access private resource denied)'.
(Details: serial 225 error_code 10 request_code 130 (MIT-SHM) minor_code 1)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the GDK_SYNCHRONIZE environment
variable to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
```
It's not the first time getting this error but it used to get fixed randomly, not sure how or why. I've also tried to run `xhost +` mentioned in #115 but nothing changes.
Is there anything I can do to debug the issue? I've tried multiple potential solutions from this thread but it didn't make any difference.
I'm on archlinux using the latest image available (it also happens with ventura, I haven't tested older images).
```
╰─$ docker inspect sickcodes/docker-osx:latest
...
"Id": "sha256:b96a4d6696f4ffaf9e4cc99493fffb8288ba6e8606a4030f7553c9e1714653db",
...
```
i did an xhost +. i'm on debian 12. i run x11 (no wayland) as a user, and the docker command. user is in the kvm and docker groups.
btw what is -v /tmp/.X11-unix:/tmp/.X11-unix for? isn't DISPLAY=:0 enough?
@jayenashar commented on GitHub (Feb 5, 2025):
same here.
command: `docker run --name macos -it --device /dev/kvm -p 50922:10022 -v /tmp/.X11-unix:/tmp/.X11-unix -e "DISPLAY=${DISPLAY:-:0.0}" -e GENERATE_UNIQUE=true -e CPU='Haswell-noTSX' -e CPUID_FLAGS='kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on' -e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom-sonoma.plist' -e SHORTNAME=sonoma sickcodes/docker-osx:latest` (with and without `sudo`)
image: `"Id": "sha256:b96a4d6696f4ffaf9e4cc99493fffb8288ba6e8606a4030f7553c9e1714653db",`
i did an `xhost +`. i'm on debian 12. i run x11 (no wayland) as a user, and the docker command. user is in the kvm and docker groups.
btw what is `-v /tmp/.X11-unix:/tmp/.X11-unix` for? isn't `DISPLAY=:0` enough?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @xJonathanLEI on GitHub (Oct 15, 2020).
Host: Ubuntu 20.04
CPU: AMD Ryzen 9 3950X 16-Core Processor
Using the latest image from Docker Hub:
When running this command:
It fails with:
I used to be able to successfully run Docker-OSX on an Intel Core i7-8700k on the same Ubuntu 20.04 host system (with an order Docker-OSX image version though). Is AMD somehow not supported? The error message seems to suggest this is an X Server error? But I should have X Server properly enabled on my system.
Please kindly help. Thanks in advance!
@xJonathanLEI commented on GitHub (Oct 15, 2020):
CPU details, just in case:
@xJonathanLEI commented on GitHub (Oct 15, 2020):
I guess it's not a CPU issue after all... I mean I can successfully install macOS following the instructions on OSX-KVM:
@sickcodes commented on GitHub (Oct 15, 2020):
Hey man! Interesting bug, first new bug I've seen in ages! I will test this shortly thank you for reporting.
@sickcodes commented on GitHub (Oct 15, 2020):
Current image working on my AMD R9 4900H
Given the message includes reference to shared memory try adding:
--shm-size=6GAnd possibly try that with and without
--device /dev/shm \Perhaps you are missing one of the above, or
gdk-pixbuf2is the only package I have with gdk I believe@xJonathanLEI commented on GitHub (Oct 15, 2020):
Hi! Thanks for the speedy reply! Happy to help debug the issue.
Adding
--shm-size=6Gwithout--device /dev/shm \gives the exact same log as originally posted.Adding both
--shm-size=6Gand--device /dev/shm \gives:@gruaig commented on GitHub (Oct 15, 2020):
Hey check out this page
https://github.com/moby/moby/issues/6758 down the very bottom with tmpfs
@xJonathanLEI commented on GitHub (Oct 16, 2020):
Ahh just in case, by "the same host system" I meant the same distro with the same version (20.04 LTS), not the same installation.
@sickcodes commented on GitHub (Oct 16, 2020):
Yeah
-v /dev/shminstead of device should fix it@sickcodes commented on GitHub (Oct 16, 2020):
-v /dev/shm --tmpfs /dev/shm:rw,nosuid,nodev,exec,size=4gSHM is a ramdisk for anyone reading this, you can see it with
dfand if you put files in the mountpoint, like/tmpyour system stores those files in RAM.@xJonathanLEI commented on GitHub (Oct 17, 2020):
Thanks for the update!
So I changed
--device /dev/shmto-v /dev/shmand now Docker doesn't complain anymore, except qemu is again showing the same error message:Here's the full command I'm using for running the container:
@sickcodes commented on GitHub (Oct 17, 2020):
I think because you're running as sudo, sudo is a different environment, are you running your display manager as sudo too?
You should add yourself to the Docker group, or I believe there's some way to do it without root.
@gruaig commented on GitHub (Oct 17, 2020):
Will give it a try but I don't believe that will be the case. Will update
shortly
On Sat 17 Oct 2020, 4:13 PM sickcodes, notifications@github.com wrote:
@xJonathanLEI commented on GitHub (Oct 17, 2020):
Hmmmm I didn't expect this to work, as I always used
sudofor Docker commands and haven't had issues with Docker-OSX on my previous machine.But somehow it works... though I seriously doubt it's the cause.
So here's what I did. I booted into the system, added myself to the Docker group, got rid of
sudoin the command, and boom, it works.But then I remove the container, add
sudoback to the command, and run it again. It still works...I even removed both
--shm-size=6Gand-v /dev/shmoptions, and it still works.So my command is now:
and runs without issue.
It seems that somehow the issue automatically went away on my machine. I'll try to find a way to reproduce it thought.
@sickcodes commented on GitHub (Oct 17, 2020):
It's probably a combination of
-Docker group
-Running as sudo
-Your desktop isn't sudo (normal)
-We are using X11 forwarding into the user env
Perhaps on previous machine, you had different groups set up
@sickcodes commented on GitHub (Oct 17, 2020):
And running the Docker daemon as root/user
I run mine as root
@xJonathanLEI commented on GitHub (Oct 17, 2020):
Hmm both machines are (almost) clean installations of Ubuntu 20.04 with no changes on user/group.
But if that's actually the cause, why am I not seeing the issue again after I:
I'm now using the command I started with.. That's weird. I should have tested if it works right before adding my user to docker group..
@sickcodes commented on GitHub (Oct 17, 2020):
https://github.com/sickcodes/Docker-OSX/commit/07f488a470bf4f04f03b369d87e1c05b3706397d#L148
Could be related to this change made not long ago
@BackMountainDevil commented on GitHub (Jul 2, 2021):
Hi, I wonder how you achieve the markdown gammar. I copy your reply md code to vscode to preview. it will not be folded...
@JetpackDuba commented on GitHub (Dec 12, 2024):
I've been facing the same issue if I'm not mistaken:
It's not the first time getting this error but it used to get fixed randomly, not sure how or why. I've also tried to run
xhost +mentioned in #115 but nothing changes.Is there anything I can do to debug the issue? I've tried multiple potential solutions from this thread but it didn't make any difference.
I'm on archlinux using the latest image available (it also happens with ventura, I haven't tested older images).
@jayenashar commented on GitHub (Feb 5, 2025):
same here.
command:
docker run --name macos -it --device /dev/kvm -p 50922:10022 -v /tmp/.X11-unix:/tmp/.X11-unix -e "DISPLAY=${DISPLAY:-:0.0}" -e GENERATE_UNIQUE=true -e CPU='Haswell-noTSX' -e CPUID_FLAGS='kvm=on,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on' -e MASTER_PLIST_URL='https://raw.githubusercontent.com/sickcodes/osx-serial-generator/master/config-custom-sonoma.plist' -e SHORTNAME=sonoma sickcodes/docker-osx:latest(with and withoutsudo)image:
"Id": "sha256:b96a4d6696f4ffaf9e4cc99493fffb8288ba6e8606a4030f7553c9e1714653db",i did an
xhost +. i'm on debian 12. i run x11 (no wayland) as a user, and the docker command. user is in the kvm and docker groups.btw what is
-v /tmp/.X11-unix:/tmp/.X11-unixfor? isn'tDISPLAY=:0enough?