starred/Docker-OSX
1
0
Fork 0
mirror of https://github.com/sickcodes/Docker-OSX.git synced 2026-01-11 21:10:25 +01:00
Code Issues 411 Packages Projects Releases Wiki Activity

Container fails to run: Gdk-ERROR #77

New Issue
Closed
opened 2025-12-28 23:23:13 +01:00 by adam · 20 comments
adam commented 2025-12-28 23:23:13 +01:00
Owner
Copy Link

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!

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!
adam closed this issue 2025-12-28 23:23:13 +01:00
adam commented 2025-12-28 23:23:14 +01:00
Author
Owner
Copy Link

@xJonathanLEI commented on GitHub (Oct 15, 2020):

CPU details, just in case:

 *-cpu
      description: CPU
      product: AMD Ryzen 9 3950X 16-Core Processor
      vendor: Advanced Micro Devices [AMD]
      physical id: 3b
      bus info: cpu@0
      version: AMD Ryzen 9 3950X 16-Core Processor
      serial: Unknown
      slot: AM4
      size: 2195MHz
      capacity: 3500MHz
      width: 64 bits
      clock: 100MHz
      capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp x86-64 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca cpufreq
      configuration: cores=16 enabledcores=16 threads=32
@xJonathanLEI commented on GitHub (Oct 15, 2020): CPU details, just in case: *-cpu description: CPU product: AMD Ryzen 9 3950X 16-Core Processor vendor: Advanced Micro Devices [AMD] physical id: 3b bus info: cpu@0 version: AMD Ryzen 9 3950X 16-Core Processor serial: Unknown slot: AM4 size: 2195MHz capacity: 3500MHz width: 64 bits clock: 100MHz capabilities: lm fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp x86-64 constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate sme ssbd mba sev ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif umip rdpid overflow_recov succor smca cpufreq configuration: cores=16 enabledcores=16 threads=32
adam commented 2025-12-28 23:23:15 +01:00
Author
Owner
Copy Link

@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:

Screenshot from 2020-10-15 14-55-25

@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): ![Screenshot from 2020-10-15 14-55-25](https://user-images.githubusercontent.com/19556359/96087482-81f51b80-0ef6-11eb-8489-7aa2b7bfe6cc.png)
adam commented 2025-12-28 23:23:15 +01:00
Author
Owner
Copy Link

@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): Hey man! Interesting bug, first new bug I've seen in ages! I will test this shortly thank you for reporting.
adam commented 2025-12-28 23:23:15 +01:00
Author
Owner
Copy Link

@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

@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
adam commented 2025-12-28 23:23:16 +01:00
Author
Owner
Copy Link

@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
@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
adam commented 2025-12-28 23:23:16 +01:00
Author
Owner
Copy Link

@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

@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
adam commented 2025-12-28 23:23:17 +01:00
Author
Owner
Copy Link

@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.

@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**.
adam commented 2025-12-28 23:23:17 +01:00
Author
Owner
Copy Link

@sickcodes commented on GitHub (Oct 16, 2020):

Yeah -v /dev/shm instead of device should fix it

@sickcodes commented on GitHub (Oct 16, 2020): Yeah `-v /dev/shm` instead of device should fix it
adam commented 2025-12-28 23:23:17 +01:00
Author
Owner
Copy Link

@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.

@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.
adam commented 2025-12-28 23:23:17 +01:00
Author
Owner
Copy Link

@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
@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
adam commented 2025-12-28 23:23:19 +01:00
Author
Owner
Copy Link

@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.

@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.
adam commented 2025-12-28 23:23:19 +01:00
Author
Owner
Copy Link

@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
.

@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> > . >
adam commented 2025-12-28 23:23:19 +01:00
Author
Owner
Copy Link

@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.

@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.
adam commented 2025-12-28 23:23:20 +01:00
Author
Owner
Copy Link

@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): 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
adam commented 2025-12-28 23:23:21 +01:00
Author
Owner
Copy Link

@sickcodes commented on GitHub (Oct 17, 2020):

And running the Docker daemon as root/user

I run mine as root

@sickcodes commented on GitHub (Oct 17, 2020): And running the Docker daemon as root/user I run mine as root
adam commented 2025-12-28 23:23:21 +01:00
Author
Owner
Copy Link

@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..

@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..
adam commented 2025-12-28 23:23:22 +01:00
Author
Owner
Copy Link

@sickcodes commented on GitHub (Oct 17, 2020):

07f488a470 (L148)

Could be related to this change made not long ago

@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
adam commented 2025-12-28 23:23:22 +01:00
Author
Owner
Copy Link

@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...
adam commented 2025-12-28 23:23:23 +01:00
Author
Owner
Copy Link

@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",
...
@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", ... ```
adam commented 2025-12-28 23:23:23 +01:00
Author
Owner
Copy Link

@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?

@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?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
documentation
enhancement
following upstream developments
good first issue
help wanted
invalid
pull-request
Mirrored from GitHub Pull Request
 question
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/Docker-OSX#77
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?