MacOS Terminal Server?

I must admit that I had never seriously used a Macintosh until the nice new iMac turned up in our office with its big, shiny, wipe clean screen (for when the Apple fanboys lick it). This was to be shared among us poor, deprived Windows users (who are actually not deprived at all as we all run Ubuntu Linux under VMWare and are perfectly happy). Actually there was one specific Mac application it was bought for us all to run; A proprietary Mac application with no Windows or Linux version no less. Ho hum.

Anyway, I thought, why should I get up from my desk and sit in front of the iMac just to use one application? Lets see what this thing can do in terms of remote access. The machine is not exposed to the internet so I had a go.

First up, I enabled SSH access. That was very easy, just one tick in the settings and we were good to go. SSH in using PuTTY? Fine. Run xclock? Fine. xclock got forwarded to my PC and displayed using the Cygwin X11 server. Run a native MacOS application? Er, yes, sort of. It appears on the local screen not on the remote client machine. This is because, although MacOS has an X11 server and some standard X11 applications installed as standard, it doesn’t actually use X11 for its own applications. Idiots! Anybody who can go to all the trouble of making X11 work on their OS and then decides not to use its amazing abilities is greatly insane.

So on to the “Screen Sharing” feature, which is really a VNC server. In MacOS 10.6 (Snow Leopard) this behaves much as it does on Windows, it shares the screen. It also performs like a dog compared to TightVNC on Windows. Even after turning off as much of the pointless eye candy as possible, to reduce the graphics being shipped over the VNC, it was terribly sluggish.

Fortunately the iMac was eligible for a free upgrade to MacOS 10.7 (Lion) and that has a multi-user VNC server in it. I loaded that and the initial results were encouraging. Then they were not. The system would occasionally hang with four-squashed-beachballs-of-coma and the only way to rouse it was to SSH in and kill the offending processes. That problem seems to have gone away with the update to MacOS 10.7.1. The VNC performance is much improved too. Finally we have a winner!

OK, so here is what you need to do to get it working:

  • Make sure you are running MacOS 10.7.1 fully patched.
  • Make sure you have a decent amount of RAM. Having multiple users requires enough RAM to go round.
  • Enable the screen sharing. You don’t need to put a password on it if all your users have passwords of their own.
  • Make the users you want, if they do not already exist.

The way it works is a bit weird and reflects a confusion about whether this is “screen sharing” or “terminal serving”.

First up, when you VNC in you get the MacOS login screen. This is why I said you don’t need to password protect the VNC, unless you really want to.

If a user is logged on locally and the remote user logs in as the same user then they will share the screen. Presumably this is what is wanted.

If no user is logged on locally and a remote user logs in their session is also shown on the local screen. This may or may not be what is wanted.

If a user is already logged in and another user logs in over the VNC then a brand new session is created for them that does not affect the existing one. This is not displayed locally and is only accessible through the VNC server.

Pros and Cons:


  • It works! You can have multiple users logged in at the same time and doing useful work without interfering with each other. Woo Hoo!
  • Performance is acceptable. VNC is never going to be as fast as RDP or ICA but, if you select a plain background image, it works OK.
  • It is free. OK, you have to pay for the OS, but it is a free feature. You don’t need to buy CALs or anything.
  • You don’t need MacOS Server. It works in the normal desktop MacOS.
  • Most applications will run for multiple users simultaneously without interference.


  • General weirdness: The fact that some sessions are on the screen and some are not. Also the privacy and security implications of this.
  • Not clear what happens when a local user wants to get on and there is a remote user already on.
  • You can’t set a preferred screen resolution for VNC without it affecting future local sessions as well.
  • No optimisation in the GUI to reduce the graphics load on the VNC connection. Why can’t you turn off the stupid window shadows and animations on maximising/minimising/etc?
  • Some VNC clients seem to find the Mac VNC server problematic. If they seize up, try enabling the local cursor and disabling the remote one. That worked for me on Snow Leopard. Maybe this is not necessary on Lion but I have not tried changing it back to normal.
  • Badly written applications may interfere if two users run them at once.
  • See The BIG Caveat…

The BIG Caveat

Now you may be thinking this is the solution to all your problems. You can deploy MS Office to multiple concurrent users without paying for loads of Windows Terminal Services CALs. Well, yes you can but check the EULA on MS Office and any other applications your remote users may want to run. You may need to buy at least as many licences as you may have concurrent users, maybe even more if they want to be really nasty about it.

Comparison with Other Remote Desktop Systems

Feature/OS MacOS 10.7 Windows Server Unix & Linux
Protocol VNC RDP VNC / X11
Performance Fair Excellent Fair / Fair
Bandwidth Low Very low Low / High
Server Cost (excluding base OS cost) Free 2 admin users free or megabucks for non-admin users Free / Free
Client cost Free, cross platform Free, cross platform (unofficially) Free, cross platform
Openness Open Proprietary but successfully reimplemented Open / Open

Note: Windows XP/Vista/7 Remote Desktop is not included as it does not allow multiple concurrent users.


It hasn’t turned me into a Mac fanboy. In fact, I have found many instances where the MacOS experience has been depressingly similar to the Windows one. To the fanboy claim that “It just works” we should add “except when it doesn’t.”

Still, having multiple concurrent users for no extra cost is pretty damn cool and it does make a Mac look a lot more like a proper computer and a lot less like an overpriced toy.

Of course it would be churlish to point out that X11 based Unix/Linux systems have had multiple, concurrent remote desktops since XDMCP was introduced  in 1989 and that even most of the proprietary Unixes don’t charge extra for it.


August 28, 2011. IT.


  1. Michael replied:

    What VNC client did you find that actually supports Per-user screen sharing? TightVNC says “Server did not offer supported security type” and refuses to connect. RealVNC says “To connect to Apple Remote Desktop (10.4) or Screen Sharing/Remote Management (10.5 onwards) built-in to Mac OS X, turn on the ‘VNC viewers may control screen with password’ option.” which of course is grossly unacceptable because turning on the password disables per-user screen sharing! UltraVNC says “No supported authentication methods!”

    This is driving me crazy,btw.

  2. danielrigal replied:

    I am using TightVNC but not the way you are trying to. I think you are trying to find a way to make the VNC client log in as a Mac user. I know that some VNC clients sort of support this but I never saw it work and I was keen to use a generic client if I could.

    The way I do it, there is a single VNC password, which is shared by all the users and is just to keep casual interlopers from getting a look at the list of users shown on the login page. This is the option you say is grossly unacceptable. I am guessing that this means you think it will just connect the anonymous user to the locally logged on session without any further authentication. Don’t worry. It doesn’t!

    What it does is send the anonymous user to the MacOS login screen where they need to give their own username and password. If they log in there as a user who is already logged in then they get connected to the existing session for that user but otherwise it starts a new session for that user which does not affect any other logged in users (local or remote). It is just like connecting to Windows Terminal Services or XDMCP without giving a username and password in advance in that you are given the OS’s login screen once you connect and you won’t get any further than that unless you log in as a valid user.

    So, my recommendation is to give the “grossly unacceptable” option a go (maybe on a test system if you are worried) and see if it really is as bad as you think.

    Using TightVNC as a client is reasonably reliable, It tends to drop the connection if the session’s resolution changes but you can log straight back in again and carry on where you were before so that is only a small annoyance. It is not 100% reliable with concurrent users but it works OK most of the time. I have seen it seize up the Mac to the point where the desktop sessions become unresponsive, even the local one, and had to ssh in and kill stuff. Not very often though. It seems better now than it was when this feature was first introduced so I guess some bugs were fixed by updates.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Trackback URI

%d bloggers like this: