Can't login to local MacOS 14.3 (Sonoma) users remotely

azac · 2024-01-25T13:14:14+00:00

There was an error rendering this rich post.

Hi team,

I'd like to report an annoying problem I encounter when I try to reach MacOS remote machines from my Windows11 computer: when I have to remote in, if the user has not logged himself in MacOS, I'm stucked on the login screen (screen frozen) after entering the user password. After few minutes, I tried to terminate the TeamViewer session and connect again, and the connection is not possible with the "standard" TeamViewer error message: "No connection to partner! Partner did not connect to router...". Even if the remote user log me in his MacOS user account, when I need to switch to another user, I can go to the switch user MacOS window but I'm stucked right after entering the password and pressing enter.

I have to ask the remote users to log me in each time I need to reach the machine whereas TeamViewer is automatically started on the remote machine, with full access, desktop and files access have been granted in MacOS Sonoma Confidentiality center, etc.

It happens with both the current TeamViewer 15.50.5 (64bits) and previous 15.49.x (versions aligned on both local and remote machines), either with new or legacy interface on both sides. It seems to me the problem occurred right after upgrading from MacOS 14.2.1 to 14.3.

Anybody else having this trouble?

Thanks for your help!

Find more posts tagged with

Remote control

macOS

Accepted answers

All comments

azac

Hi all,

Any feedback regarding that issue?

Does your R&D has reproduced similar behavior internally?

Br,

azac

Hi @MoreCoffee,

Thanks for your answer. No: I speak when the you are on the MacOS log in screen with the available user accounts ready to connect. Until you log in to one of the user, there is no other way to remote access to the machine. This means you can't restart the machine remotely without having somebody onsite to log in to any of the available user. It's unbelievable as TeamViewer should start as a background service and do not care of users consideration as it does for both Linux and Windows...

Any idea?

MoreCoffee

@azac I see, thanks for the clarification.

I assume you do have Start with macOS (Start with system) turned on in TeamViewer?

If you do: Do you have FileVault turned on this Mac?

If you have FileVault enabled, the login screen you are seeing when your Mac boots is not the "real" macOS login screen. What you are seeing there is the FileVault unlock screen. At this point, macOS will not actually be running, and neither will any 3rd party apps or services (because everything is on the disk that is still encrypted at this point).

Once FileVault is unlocked, macOS will actually boot (and immediately log in the user account that was used at the FileVault unlock screen, without showing another login screen).

There are two options to work around this for unattended access:

Turn off FileVault. This may sound insecure, but given that modern Macs with Apple Silicon CPU or Intel Macs with T2 chips already come with some level of full disk encryption by default, it might be secure enough for your use case. You can find more information about this in Apple's Platform Security Guide: https://support.apple.com/guide/security/volume-encryption-with-filevault-sec4c6dc1b6e/web
Leave FileVault on. After logging in once after boot, you can log out your user accountand later log back in remotely, as long as you don't reboot the Mac. If you do need to reboot remotely, use the command sudo fdesetup authrestart in Terminal. This command is able to reboot your Mac and unlock FileVault at boot, so macOS will actually be fully booted at the "real" login screen. The same applies to most macOS updates – in my experience, they usually also unlock FileVault again after the necessary reboot. Of course this doesn't help in cases of power loss or macOS crashes, and you probably still want someone on site with an account that is able to unlock FileVault on this Mac for such issues.

azac

@MoreCoffee, indeed: "Start With" setting is enabled and FileVault is turned on too. But, on Windows, even with BitLocker enabled, I didn't have such limitation. But I appreciate your help and detailed explanation. Your second solution sounds the best compromise. I'm going to test it soon and let you know if I still encounter any trouble.

Meanwhile, do you think an improvement is feasible on TeamViewer side? For example a built-in feature to automatically launch such command via TeamViewer and restart MacOS and unlocking FileVault at the same time?

Thanks again for your good feedback.

MoreCoffee

Hi @azac ,

Do I understand correctly that you are having this issue at the point where macOS displays the Setup Assistant for a new user account (or after macOS updates, e.g. to ask again if a user would like to set up Screen Time, Touch ID etc.)?

If that's the case: It is unfortunately not possible for TeamViewer to provide remote access at that point, as the system is kind of "stuck" in a state between the login screen and the user account being fully logged in.

It is, however, possible to prevent the Setup Assistant from appearing for newly created user accounts and/or after updates.

To turn the Setup Assistant off for any account created in the future, you will need to modify the templates in /System/Library/User Template.
To make macOS think the setup has already run for a newly created account you can modify its settings prior to logging in for the first time.

Here's an example of a script to do this (not that the script is not provided by TeamViewer, so use at your own risk):

https://github.com/rtrouton/rtrouton_scripts/blob/master/rtrouton_scripts/disable_apple_icloud_data_privacy_diagnostic_touch_id_siri_activation_lock_and_screentime_pop_ups/disable_apple_icloud_data_privacy_diagnostic_touch_id_siri_activation_lock_and_screentime_pop_ups.sh

The first part of the script modifies the user templates, affecting any users created from that point on. The second part makes macOS think the setup has already run on existing user accounts.