Server for macOS?

[ghost]

Has anyone managed to succesfully get the server software running on macOS and if so how did you do it?

I know docker can be installed on macOS but don't know if it will work.

[paspo]

There's no support for plain OSX, as the install base will be too small to justify the effort.

docker is your best option, at the moment; it works on amd64 and should work on M1 / M2 (please report if it's working or not)

[rustdesk]

docker amd64 worked on my old mac, but -host option not worked on mac.

[ghost]

Is there a complete idiot guide to installing the server with docker and configuring etc?

I've had a hunt on the internet but can't find anything that involves hand-holding this idiot :)

[paspo]

docker amd64 worked on my old mac, but -host option not worked on mac.

I think this is due to the fact that docker on osx runs on a separate (hidden) virtual machine, not natively like on linux.

[ghost]

Is there a complete idiot guide to installing the server with docker and configuring etc?

I've had a hunt on the internet but can't find anything that involves hand-holding this idiot :)

[miguelagve]

This tutorial seems to show a full guide to installing rustdesk-server on MacOS. You might want to take a look to see if it helps https://www.youtube.com/watch?v=SYM6M5Fiuyc

[ghost]

Very informative. Will give it a try and see how I get on.

Thanks.

On 3 Sep 2022, at 13:09, Miguel Agueda @.***> wrote:

This tutorial seems to show a full guide to installing rustdesk-server on MacOS. You might want to take a look to see if it helps https://www.youtube.com/watch?v=SYM6M5Fiuyc <x-msg://1/url> — Reply to this email directly, view it on GitHub https://github.com/rustdesk/rustdesk-server/issues/102#issuecomment-1236097737, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2NS74QAMQJXPYS22BIJHDTV4MWW3ANCNFSM57N74OQA. You are receiving this because you authored the thread.

[Simbaclaws]

I've been diving into how I can get this to work for some time now and here are my findings. I hope this can help the maintainer, and perhaps any other contributors look at this issue in a more in-depth manner.

The problem:

Mac OS works differently then windows and linux do when it comes to the docker engine. Mac OS uses Hyperkit to create a virtual machine kind of infrastructure for docker containers, where it will create it's own network bridges in order to communicate with different containers.

This means that there are a few problems that need to be overcome in order for a client to be able to connect to a server.

First and foremost:

1. You can't set the network mode to host

Docker for Mac does not support the host network mode like it does on Linux. When you use --network="host" on Docker for Mac, it will not behave the same way as it does on Docker for Linux. This difference arises due to the underlying architecture of Docker on Mac, which uses a hypervisor (HyperKit) to run a lightweight Linux VM to actually run the containers. The host for the container in this case is the VM and not the macOS host itself.

This means if you run a container with --network="host" on Docker for Mac, the container will share the network namespace with the Linux VM, not the Mac host.

If you need the container to be reachable from the Mac host or other devices on the same network, you'll typically publish ports using the -p option, like -p 8080:8080, which maps port 8080 inside the container to port 8080 on the Mac host.

This means I have to adjust the docker-compose.yaml to at least look like this:

version: '3'

services:
  hbbs:
    container_name: hbbs
    image: rustdesk/rustdesk-server:latest
    command: hbbs
    volumes:
      - ./data:/root
    ports:
      - "21115:21115"
      - "21116:21116"
      - "21118:21118"
      - "21116:21116/udp"
    depends_on:
      - hbbr
    restart: unless-stopped

  hbbr:
    container_name: hbbr
    image: rustdesk/rustdesk-server:latest
    command: hbbr
    volumes:
      - ./data:/root
    ports:
      - "21117:21117"
      - "21119:21119"
    restart: unless-stopped

Save this into a compose.yaml file in some directory, and run docker-compose up to bring the containers up...

2. If you have your firewall setup in Mac OS, you will have to include docker to allow connections to the outside. This should be done as followed:

• Open System Preferences > Security & Privacy.
• Select the Firewall tab.
• Click the lock icon and authenticate to make changes.
• Click on Firewall Options....
• Press the "+" sign, locate and add the Docker app.
• Set Docker to "Allow incoming connections".
• Click "OK" and close the window.

3. Mac OS needs accesibility and screen recording capabilities for docker in order to send through the connections, these can be found here:

• Open System Preferences and select “Security & Privacy”.
• Navigate to the “Privacy” tab.
• For Accessibility:
  • Select "Accessibility" in the left panel.
  • Unlock using the bottom-left lock icon if needed.
  • Check the box next to your Docker-related application or add it manually using "+".
• For Screen Recording:
  • Select "Screen Recording" in the left panel.
  • Grant permission similarly as for accesibility.
  • Restart the application or Docker container for permissions to take effect.
  • Ensure your Docker container is correctly configured to interact with macOS features.

4. Mac OS can only access the relay_server from localhost.....

This is where the real pain comes in: Since Mac OS uses network bridges in order to communicate with docker images, whatever request you make from the outside will have it's ip address masked to be the ip address of the network bridge instead.

Because the application written in rust basically uses raw TCP Streams, it can not figure out the fact that the ip address that came from the original request was the one needing to be requesting access...

You can see this happening in your logs, once you connect to the docker image, you will see that the request comes from an internal docker network bridge if you are connecting from the outside such as: 192.168.65.1

The problem lies in the fact that raw TCP streams do not have extra functionality such as a X-Forwarded-IP header like a HTTP request does, because we're talking raw TCP streams, the TCP stream can only interact with the direct source ip address it came from.

This means that in order to make the linux docker container work on Mac OS, a few things needs to happen:

Conclusion

• The client that is sending the request to the server, should somehow communicate it's direct ip address to the server, instead of relying on a raw TCP stream to fetch the IP address.

• This means that the server should be able to figure out whether a IP address comes from it's direct neighbour, or whether it comes from the actual source...

This would allow not only Mac OS to be able to host the image, but also would mean that proxy's and NAT's can be used inside of the application as well....

[Simbaclaws]

I would contribute a fix if I knew how to write rust, I'm quite rusty when it comes to rust. When I find spare-time, I might dive into this deeper, to perhaps contribute a fix. Because I really need a good remote desktop solution.

[Simbaclaws]

Because the pro version of rustdesk server comes with native binaries for the platform you want to use, you could use the native binary instead and turn it into an app that you can run on startup... Native binaries don't have bridges inbetween, and tend to communicate the ip address directly towards the mac os server.

Basically what I did to get it to work, was run the sh file that was extracted in a app that I made with automator. This would allow you to run that app on startup. And give it the correct permissions. I also enabled automatic login on my mac in order to be able to boot it on reboot and on startup.

This allows for mac os to be able to host the server instance. (Pro version)

However, I've only been able to work with that until the latest mac os update, which for some reason made my setup fail. I haven't been able to get it to work afterwards.

For now I've decided to go with a ubuntu server setup on a different device to host the rustdesk server on, because it seems to be more stable and allows for the nightly build of the rustdesk server to run, which allows for multiple remote monitor support.