macos How to use full Screen Sharing?

Operating system

Syno DSM

Description

Using the plain VNC protocol to access the macOS VM is quite painful when you're trying to control the VM from a Mac. Ideally, the Mac's Screen Sharing app should be used for the best user experience. However, even when I open all the related ports, it Screen Sharing cannot connect:

    ports:
      - 8006:8006
      - 5900:5900/tcp
      - 5900:5900/udp
      - 5901:5901/udp
      - 5902:5902/udp
      - 3283:3283/tcp
      - 3283:3283/udp
      - 88:88

I believe that's because qemu inserts its own vnc server. So I need to disable that "feature". Googling the problem I found that qemu has a cmdline option for that: "--disable-vnc". But since we're using docker compose here, I cannot figure out how to apply this option.

So, how what must I change to have the docker container run qemu without activating its vnc-server?

And may I then also suggest to add this "trick" to the readme?

Update

I also tried adding the two environment vars suggested in https://github.com/dockur/macos/issues/131#issuecomment-2480851179 but that, while it seems to disable the qemu vnc service, still won't let me login via Screen Sharing (while I can still ssh into the VM). Now the connection attempt times out, though I can see that port 5900 is listening on the Mac.

Here's the config I'm currently using (the "NETWORK: user" settings seems to be needed, or I can't even ssh into the Mac):

services:
  macos:
    image: dockurr/macos
    container_name: macos12
    environment:
      VERSION: "12"
      RAM_SIZE: "8G"
      CPU_CORES: "2"
      DISK_SIZE: "128G"
      WIDTH: "1440"
      HEIGHT: "960"
      NETWORK: "user"
      USER_PORTS: "5900"
      DISPLAY: "disabled"
    devices:
      - /dev/kvm
      - /dev/net/tun
    cap_add:
      - NET_ADMIN
    ports:
      - 8006:8006
      - 5900:5900/tcp
      - 5900:5900/udp
      - 5901:5901/udp
      - 5902:5902/udp
      - 8022:22
    volumes:
      - ./macos12:/storage
    restart: "no"  # on-failure:2
    stop_grace_period: 2m

Apr 23 '25 10:04 tempelmann

Try:

environment:
  DISPLAY: "disabled"

to disable VNC.

Apr 23 '25 11:04 kroese

Thanks, see my updated post. Already tried that. It disabls the Qemu VNC, but now I get a timeout. So, something else blocks port 5900 or something, I suspect. The thing is that on the host side it looks like all ports are properly forwarded:

root@Syno:~# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DEFAULT_FORWARD  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain DEFAULT_FORWARD (1 references)
target     prot opt source               destination         
DOCKER-USER  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     all  --  anywhere             anywhere            

Chain DOCKER (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:ssh
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:8006
ACCEPT     udp  --  anywhere             172.18.0.2           udp dpt:5902
ACCEPT     udp  --  anywhere             172.18.0.2           udp dpt:5901
ACCEPT     tcp  --  anywhere             172.18.0.2           tcp dpt:5900
ACCEPT     udp  --  anywhere             172.18.0.2           udp dpt:5900

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination         
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            
DROP       all  --  anywhere             anywhere            
RETURN     all  --  anywhere             anywhere            

Chain DOCKER-USER (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere

And macOS also has the port 5900 open:

Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)     rhiwat shiwat    pid   epid  state    options
tcp4       0      0  *.88                   *.*                    LISTEN      131072 131072    129      0 0x0180 0x00000006
tcp6       0      0  *.88                   *.*                    LISTEN      131072 131072    129      0 0x0180 0x00000006
tcp4       0      0  *.5900                 *.*                    LISTEN      131072 131072      1      0 0x0180 0x00000006
tcp6       0      0  *.5900                 *.*                    LISTEN      131072 131072      1      0 0x0180 0x00000006
tcp4       0      0  *.22                   *.*                    LISTEN      131072 131072      1      0 0x0180 0x00000006
tcp6       0      0  *.22                   *.*                    LISTEN      131072 131072      1      0 0x0180 0x00000006

Yet, something in between seems to block the communication.

Any ideas where else to look?

Apr 23 '25 11:04 tempelmann

Some more testing shows that I need to add

    environment:
      USER_PORTS: "5900"

as well or the 5900 isn't reachable. But with this additional option, I still get a timeout.

Oh, wait! It's not a timeout any more, I now get the expected login dialog (with user name) - but it took maybe half a minute or more. And connecting also takes a long time again. But eventually it connects. So, it's just like #131 wrote - it works, but for me the connection process takes minutes, and once connected, it's laggy. Well, better than nothing.

I've compared the open ports used by the screensharing daemon with a real Mac's, and they're the same - only 5900 is used. So, it's not that screen sharing needs additional ports besides 5900 (no need for 5901 and 5902 as suggested on on several Apple pages, e.g. https://support.apple.com/guide/mac-help/screen-sharing-type-options-on-mac-mchl1883115d/14.0/mac/14.0 )

I'll test some more and update this comment.

Apr 23 '25 11:04 tempelmann

Normally you dont need the USER_PORTS but only if you set NETWORK: "user" as normally all ports are forwarded as soon as you include them in the compose file.

Apr 23 '25 11:04 kroese

Normally you dont need the USER_PORTS but only if you set NETWORK: "user" as normally all ports are forwarded as soon as you include them in the compose file.

Thanks. Confirmed: I can remove both USER_PORTS and NETWORK and it still works the same.

So, adding DISPLAY: "disabled" is the key to use Screen Sharing, but that doesn't work perfectly because:

The connection takes over 30s to initiate.
The performance isn't fluid. I wonder if that's because Qemu doesn't use a "proper" hardware screen, so the screensharing daemon must resort to rather inefficient methods to detect screen changes. However, when macOS is fairly idle, the "top" cmd on the Syno system shows that it uses about 6% CPU, so maybe that's not it.

But since this allows us to transfers files (via drag & drop) and use all the proper keyboard shortcuts, I suggest you add this option to the Readme, with the warning of the connection delay and the low performance.

Feel free to close this when you've read this. And thank you for making this possible!

Apr 23 '25 12:04 tempelmann