starred/Docker-OSX-sickcodes
1
0
Fork 0
mirror of https://github.com/sickcodes/Docker-OSX.git synced 2026-01-14 07:33:30 +01:00
Code Issues 411 Packages Projects Releases Wiki Activity

Another gtk initialization failed ubuntu 20 #484

New Issue
Open
opened 2025-12-29 06:20:26 +01:00 by adam · 5 comments
adam commented 2025-12-29 06:20:26 +01:00
Owner
Copy Link

Originally created by @89jd on GitHub (Mar 15, 2023).

OS related issued, please help us identify the issue by posting the output of this

:1
1
PRETTY_NAME="Ubuntu 22.04.1 LTS"
NAME="Ubuntu"
VERSION_CODENAME=jammy
UBUNTU_CODENAME=jammy
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme1n1p5  561G  514G   19G  97% /home
QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.6)
Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers
libvirtd (libvirt) 8.0.0
               total        used        free      shared  buff/cache   available
Mem:            15Gi       8.8Gi       237Mi       840Mi       6.4Gi       5.4Gi
Swap:           15Gi       6.1Gi       9.6Gi
16
32
crw-rw----+ 1 root kvm 10, 232 Mar 15 22:47 /dev/kvm
total 2.1M
drwxrwxrwt  2 root root 4.0K Mar 13 16:12 .
drwxrwxrwt 41 root root 2.1M Mar 15 22:48 ..
srwxrwxrwx  1 jack jack    0 Mar 13 16:12 X1
root        1132  0.1  0.3 5180040 63960 ?       Ssl  Mar13   4:37 dockerd --group docker --exec-root=/run/snap.docker --data-root=/var/snap/docker/common/var-lib-docker --pidfile=/run/snap.docker/docker.pid --config-file=/var/snap/docker/2746/config/daemon.json
root        4836  0.0  0.0 2277656 13184 ?       Ssl  Mar13   0:23 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
jack      374261  0.0  0.0   9212  2476 pts/1    S+   22:49   0:00 grep --color=auto dockerd
kvm:x:108:jack
docker:x:134:jack
libvirt:x:140:jack
libvirt-qemu:x:64055:libvirt-qemu
libvirt-dnsmasq:x:141:

xhost +

access control disabled, clients can connect from any host
Originally created by @89jd on GitHub (Mar 15, 2023). # OS related issued, please help us identify the issue by posting the output of this ```Linux jack-Blade-Pro 5.19.0-35-generic #36~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb 17 15:17:25 UTC 2 x86_64 x86_64 x86_64 GNU/Linux :1 1 PRETTY_NAME="Ubuntu 22.04.1 LTS" NAME="Ubuntu" VERSION_CODENAME=jammy UBUNTU_CODENAME=jammy Filesystem Size Used Avail Use% Mounted on /dev/nvme1n1p5 561G 514G 19G 97% /home QEMU emulator version 6.2.0 (Debian 1:6.2+dfsg-2ubuntu6.6) Copyright (c) 2003-2021 Fabrice Bellard and the QEMU Project developers libvirtd (libvirt) 8.0.0 total used free shared buff/cache available Mem: 15Gi 8.8Gi 237Mi 840Mi 6.4Gi 5.4Gi Swap: 15Gi 6.1Gi 9.6Gi 16 32 crw-rw----+ 1 root kvm 10, 232 Mar 15 22:47 /dev/kvm total 2.1M drwxrwxrwt 2 root root 4.0K Mar 13 16:12 . drwxrwxrwt 41 root root 2.1M Mar 15 22:48 .. srwxrwxrwx 1 jack jack 0 Mar 13 16:12 X1 root 1132 0.1 0.3 5180040 63960 ? Ssl Mar13 4:37 dockerd --group docker --exec-root=/run/snap.docker --data-root=/var/snap/docker/common/var-lib-docker --pidfile=/run/snap.docker/docker.pid --config-file=/var/snap/docker/2746/config/daemon.json root 4836 0.0 0.0 2277656 13184 ? Ssl Mar13 0:23 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock jack 374261 0.0 0.0 9212 2476 pts/1 S+ 22:49 0:00 grep --color=auto dockerd kvm:x:108:jack docker:x:134:jack libvirt:x:140:jack libvirt-qemu:x:64055:libvirt-qemu libvirt-dnsmasq:x:141: ``` xhost + ``` access control disabled, clients can connect from any host ```
adam commented 2025-12-29 06:20:26 +01:00
Author
Owner
Copy Link

@89jd commented on GitHub (Mar 16, 2023):

Running this cmd

docker run --privileged -it \
    --device /dev/kvm \
    -p 50922:10022 \
    -v /tmp/.X11-unix:/tmp/.X11-unix \
    -e "DISPLAY=${DISPLAY:-:0.0}" \
    sickcodes/docker-osx:latest

Also if I run the command, without -v and -e for headless interestingly

@89jd commented on GitHub (Mar 16, 2023): Running this cmd ``` docker run --privileged -it \ --device /dev/kvm \ -p 50922:10022 \ -v /tmp/.X11-unix:/tmp/.X11-unix \ -e "DISPLAY=${DISPLAY:-:0.0}" \ sickcodes/docker-osx:latest ``` Also if I run the command, without -v and -e for headless interestingly
adam commented 2025-12-29 06:20:26 +01:00
Author
Owner
Copy Link

@sickcodes commented on GitHub (May 7, 2023):

Add yourself to docker group and restart the docker daemon

@sickcodes commented on GitHub (May 7, 2023): Add yourself to docker group and restart the docker daemon
adam commented 2025-12-29 06:20:26 +01:00
Author
Owner
Copy Link

@89jd commented on GitHub (May 7, 2023):

Thanks for response.

I am already added to docker group

@89jd commented on GitHub (May 7, 2023): Thanks for response. I am already added to docker group
adam commented 2025-12-29 06:20:26 +01:00
Author
Owner
Copy Link

@89jd commented on GitHub (May 7, 2023):

nohup: appending output to 'nohup.out'
++ id -u
++ id -g
+ sudo chown 1000:1000 /dev/kvm
++ id -u
++ id -g
+ sudo chown -R 1000:1000 /dev/snd
+ [[ 4 = max ]]
+ [[ 4 = half ]]
++ id -u
++ id -g
+ sudo chown -R 1000:1000 /dev/snd
+ exec qemu-system-x86_64 -m 4000 -cpu Penryn,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check, -machine q35,accel=kvm:tcg -smp 4,cores=4 -usb -device usb-kbd -device usb-tablet -device 'isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc' -drive if=pflash,format=raw,readonly=on,file=/home/arch/OSX-KVM/OVMF_CODE.fd -drive if=pflash,format=raw,file=/home/arch/OSX-KVM/OVMF_VARS-1024x768.fd -smbios type=2 -audiodev alsa,id=hda -device ich9-intel-hda -device hda-duplex,audiodev=hda -device ich9-ahci,id=sata -drive id=OpenCoreBoot,if=none,snapshot=on,format=qcow2,file=/home/arch/OSX-KVM/OpenCore/OpenCore.qcow2 -device ide-hd,bus=sata.2,drive=OpenCoreBoot -device ide-hd,bus=sata.3,drive=InstallMedia -drive id=InstallMedia,if=none,file=/home/arch/OSX-KVM/BaseSystem.img,format=qcow2 -drive id=MacHDD,if=none,file=/home/arch/OSX-KVM/mac_hdd_ng.img,format=qcow2 -device ide-hd,bus=sata.4,drive=MacHDD -netdev user,id=net0,hostfwd=tcp::10022-:22,hostfwd=tcp::5900-:5900, -device vmxnet3,netdev=net0,id=net0,mac=52:54:00:09:49:17 -monitor stdio -boot menu=on -vga vmware
QEMU 7.2.0 monitor - type 'help' for more information
(qemu) ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: Device or resource busy
ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave
alsa: Could not initialize DAC
alsa: Failed to open `default':
alsa: Reason: Device or resource busy
audio: Failed to create voice `dac'
gtk initialization failed
@89jd commented on GitHub (May 7, 2023): ```ssh-keygen: generating new host keys: RSA ECDSA ED25519 nohup: appending output to 'nohup.out' ++ id -u ++ id -g + sudo chown 1000:1000 /dev/kvm ++ id -u ++ id -g + sudo chown -R 1000:1000 /dev/snd + [[ 4 = max ]] + [[ 4 = half ]] ++ id -u ++ id -g + sudo chown -R 1000:1000 /dev/snd + exec qemu-system-x86_64 -m 4000 -cpu Penryn,vendor=GenuineIntel,+invtsc,vmware-cpuid-freq=on,+ssse3,+sse4.2,+popcnt,+avx,+aes,+xsave,+xsaveopt,check, -machine q35,accel=kvm:tcg -smp 4,cores=4 -usb -device usb-kbd -device usb-tablet -device 'isa-applesmc,osk=ourhardworkbythesewordsguardedpleasedontsteal(c)AppleComputerInc' -drive if=pflash,format=raw,readonly=on,file=/home/arch/OSX-KVM/OVMF_CODE.fd -drive if=pflash,format=raw,file=/home/arch/OSX-KVM/OVMF_VARS-1024x768.fd -smbios type=2 -audiodev alsa,id=hda -device ich9-intel-hda -device hda-duplex,audiodev=hda -device ich9-ahci,id=sata -drive id=OpenCoreBoot,if=none,snapshot=on,format=qcow2,file=/home/arch/OSX-KVM/OpenCore/OpenCore.qcow2 -device ide-hd,bus=sata.2,drive=OpenCoreBoot -device ide-hd,bus=sata.3,drive=InstallMedia -drive id=InstallMedia,if=none,file=/home/arch/OSX-KVM/BaseSystem.img,format=qcow2 -drive id=MacHDD,if=none,file=/home/arch/OSX-KVM/mac_hdd_ng.img,format=qcow2 -device ide-hd,bus=sata.4,drive=MacHDD -netdev user,id=net0,hostfwd=tcp::10022-:22,hostfwd=tcp::5900-:5900, -device vmxnet3,netdev=net0,id=net0,mac=52:54:00:09:49:17 -monitor stdio -boot menu=on -vga vmware QEMU 7.2.0 monitor - type 'help' for more information (qemu) ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave alsa: Could not initialize DAC alsa: Failed to open `default': alsa: Reason: Device or resource busy ALSA lib pcm_dmix.c:999:(snd_pcm_dmix_open) unable to open slave alsa: Could not initialize DAC alsa: Failed to open `default': alsa: Reason: Device or resource busy audio: Failed to create voice `dac' gtk initialization failed ```
adam commented 2025-12-29 06:20:27 +01:00
Author
Owner
Copy Link

@bphd commented on GitHub (Jun 28, 2023):

89jd

Unauthorized System Access: Allowing any host or user to connect to the X server without authentication creates a significant vulnerability. Malicious individuals can exploit this access to gain unauthorized control over your system and execute malicious commands.

Malware Execution: Unrestricted access provides an avenue for the execution of malicious code or malware on your system. This can lead to unauthorized activities, data theft, system damage, or the spread of malware to other connected systems.

Data Breaches: Uncontrolled access to the X server exposes sensitive information displayed by X applications. This includes personal data, confidential business information, and any other data processed or displayed through graphical interfaces. Unauthorized data access can result in reputational damage, legal consequences, and financial losses.

To mitigate these security risks, follow these best practices for X server access control:

Identify and Whitelist Trusted Hosts: Take the time to identify the specific hosts that require access to your X server. Consider the purpose and requirements of each host in your network. This could include trusted workstations, servers, or other devices that need to run X applications or access the graphical interface. By carefully evaluating and identifying these hosts, you can create a list of authorized entities.

Whitelist Only Authorized Hosts: Once you have identified the trusted hosts, whitelist them by configuring the access control settings of the X server. Use commands such as "xhost +hostname" or "xhost +SI:localuser:username@hostname" to allow only these authorized hosts to connect to the X server. This effectively restricts access to the X server to the specified entities, preventing unauthorized connections.

@bphd commented on GitHub (Jun 28, 2023): > 89jd Unauthorized System Access: Allowing any host or user to connect to the X server without authentication creates a significant vulnerability. Malicious individuals can exploit this access to gain unauthorized control over your system and execute malicious commands. Malware Execution: Unrestricted access provides an avenue for the execution of malicious code or malware on your system. This can lead to unauthorized activities, data theft, system damage, or the spread of malware to other connected systems. Data Breaches: Uncontrolled access to the X server exposes sensitive information displayed by X applications. This includes personal data, confidential business information, and any other data processed or displayed through graphical interfaces. Unauthorized data access can result in reputational damage, legal consequences, and financial losses. To mitigate these security risks, follow these best practices for X server access control: Identify and Whitelist Trusted Hosts: Take the time to identify the specific hosts that require access to your X server. Consider the purpose and requirements of each host in your network. This could include trusted workstations, servers, or other devices that need to run X applications or access the graphical interface. By carefully evaluating and identifying these hosts, you can create a list of authorized entities. Whitelist Only Authorized Hosts: Once you have identified the trusted hosts, whitelist them by configuring the access control settings of the X server. Use commands such as "xhost +hostname" or "xhost +SI:localuser:username@hostname" to allow only these authorized hosts to connect to the X server. This effectively restricts access to the X server to the specified entities, preventing unauthorized connections.
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-sickcodes#484
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?