[Bug/iCloud] iCloud login doesn't function, "An unknown error occurred."

[LunarN0v4]

Operating system

Debian GNU/Linux 12 (bookworm)

Description

iCloud login fails with "An unknown error occurred.", no actual description of the problem. I have tried every prompt in the system and they all fail with iCloud login.

Docker compose

services:
  macos:
    image: dockurr/macos
    container_name: macos
    environment:
      VERSION: "15"
      DISK_SIZE: "256G"
      RAM_SIZE: "16G"
      CPU_CORES: "8"
    devices:
      - /dev/kvm
    cap_add:
      - NET_ADMIN
    ports:
      - 8006:8006
      - 5900:5900/tcp
      - 5900:5900/udp
    stop_grace_period: 2m
    volumes:
      - ./storage:/storage

Docker log

❯ Starting macOS for Docker v1.14... ❯ For support visit https://github.com/dockur/macos ❯ CPU: Intel Xeon CPU E5 2630 v3 | RAM: 54/63 GB | DISK: 6314 GB (ext4) | HOST: 6.1.0-26-amd64...

^[[1;34m❯ ^[[1;36mDownloading macOS 15 recovery image...^[[0m Downloading 062-24352... Saving http://oscdn.apple.com/content/downloads/58/14/062-24352/huowb7csccndr18cneqn3epe6quo5yt061/RecoveryImage/BaseSystem.chunklist to /storage/tmp/BaseSystem.chunklist... ^M100.0% downloaded Download complete! Saving http://oscdn.apple.com/content/downloads/58/14/062-24352/huowb7csccndr18cneqn3epe6quo5yt061/RecoveryImage/BaseSystem.dmg to /storage/tmp/BaseSystem.dmg... ^M1.1% downloaded^M2.2% downloaded^M3.3% downloaded^M4.5% downloaded^M5.6% downloaded^M6.7% downloaded^M7.8% downloaded^M8.9% downloaded^M10.0% downloaded^M11.1% downloaded^M12.3% downloaded^M13.4% downloaded^M14.5% downloaded^M15.6% do> Download complete! Verifying image with chunklist... ^MChunk 10 (10485760 bytes)^MChunk 20 (10485760 bytes)^MChunk 30 (10485760 bytes)^MChunk 40 (10485760 bytes)^MChunk 50 (10485760 bytes)^MChunk 60 (10485760 bytes)^MChunk 70 (10485760 bytes)^MChunk 80 (10485760 bytes) Image verification complete! ^[[1;34m❯ ^[[1;36mCreating a 256G growable disk image in raw format...^[[0m ^[[1;34m❯ ^[[1;36mExtracting boot image...^[[0m ^[[1;34m❯ ^[[1;36mBooting macOS 1920x1080 using QEMU v9.1.0...^[[0m ^[[2J^[[01;01H^[[=3h^[[2J^[[01;01H^[[2J^[[01;01H^[[=3h^[[2J^[[01;01H^[[2J^[[01;01H^[[=3h^[[2J^[[01;01HBdsDxe: failed to load Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0xA,0x0): Not Found BdsDxe: loading Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x5,0x0) BdsDxe: starting Boot0002 "UEFI Misc Device 2" from PciRoot(0x0)/Pci(0x5,0x0) #[EB|LOG:EXITBS:END] _ #[EB.BST.FBS|-] #[EB|B:BOOT] #[EB|LOG:HANDOFF TO XNU] _ ======== End of efiboot serial output. ========

Screenshots (optional)

[amarkules1]

I'm having the same issue. It happens when I try to log in via the app store or settings app. I also get a similar error when I click the "Create Apple Account" button

Also running on version 15. I'll try an older MacOS version and see if the issue still happens.

Edit: same thing with version 14. After trying to log in there I started getting similar errors on my iphone. I think apple may have locked my account.

[gzepeda]

Also getting this error. Any ideas if there is some additional access needed for the docker container running MacOS?

[amarkules1]

I was able to log into iCloud after downgrading to MacOS 13 Ventura. Unfortunately you need 14.5 to install XCode which was my reason for trying this whole thing out in the first place.

[gzepeda]

If you login and then upgrade MacOS ... would that work?

[kroese]

The problem is that I do not generate unique serialnumbers for the VM upon install (like documented here: https://dortania.github.io/OpenCore-Post-Install/universal/iservices.html ). But I just use a fixed set of values that are the same for everyone, so according to Apple's servers they all look like they are the same machine.

It would be possible to fix this with a bit of effort, but I dont even have an Apple ID myself, so I am not able to test it. So hopefully someone else will take the time to implement automatic generation of unique values and submit the code to this project as a pull-request.

[amarkules1]

That makes sense, thanks for the explanation @kroese

I can take a look in the next week or so and see if I can figure it out. If anyone feels like picking it up in the meantime feel free.

[ksylvan]

@amarkules1 Did you find a way to fix this? Running into the same issue on MacOS 15 now.

[kroese]

I created a new version (v1.16). It automaticly generates unique machine values when creating a new macOS installation.

So cloud services should be working now. Can someone please test it and tell me if its fixed?

[ColaIan]

Currently on 1.16 but does not seem to be working

[LunarN0v4]

On 1.16 (pulled just now) issue persists.

[alenros]

@kroese I've found the following in a repo that runs MacOS in virtualbox, maybe that could help. It list some other variables that need to be manipulated: https://github.com/myspaghetti/macos-virtualbox

Values for NVRAM and EFI parameters are required by iCloud, iMessage, and other connected Apple applications, but otherwise not required. Parameters taken from a genuine Mac may result in a "Call customer support" message if they do not match the genuine Mac exactly. Non-genuine yet genuine-like parameters usually work. Assigning the following parameters is not required when installing or using macOS.

DmiSystemFamily="MacBook Pro" # Model Name DmiSystemProduct="MacBookPro11,2" # Model Identifier DmiBIOSVersion="string:MBP7.89" # Boot ROM Version DmiSystemSerial="NO_DEVICE_SN" # Serial Number (system) DmiSystemUuid="CAFECAFE-CAFE-CAFE-CAFE-DECAFFDECAFF" # Hardware UUID ROM='%aa*%bbg%cc%dd' # ROM identifier MLB="NO_LOGIC_BOARD_SN" # MLB SN stored in NVRAM DmiBoardSerial="${MLB}" # MLB SN stored in EFI DmiBoardProduct="Mac-3CBD00234E554E41" # Product (board) identifier SystemUUID="aabbccddeeff00112233445566778899" # System UUID

[dcontiveros]

The problem is that there are new VM restrictions on utilizing iServices. You'll need a kernel patch for this. You need to ensure the following tunable is set to 0:

kern.hv_vmm_present: 0

[LunarN0v4]

The problem is that there are new VM restrictions on utilizing iServices. You'll need a kernel patch for this. You need to ensure the following tunable is set to 0:

kern.hv_vmm_present: 0

Is it possible to achieve this by leveraging QEMU on the main machine somehow?

[alenros]

The problem is that there are new VM restrictions on utilizing iServices. You'll need a kernel patch for this. You need to ensure the following tunable is set to 0:

kern.hv_vmm_present: 0

Is this requirement in macos 15 or has it already been introduced in macos 14? If it's only in 15 then maybe a fix is possible for 14, which might be a good start or good enough for some (like me).

[dcontiveros]

macOS 14 was not impacted according to my assessment. I don't actually run this in Docker I have a full VFIO passthrough setup via libvirt/qemu.

Circumventing checks is beyond the scope of this issue I believe.

[phibersoft]

The problem is that there are new VM restrictions on utilizing iServices. You'll need a kernel patch for this. You need to ensure the following tunable is set to 0:

kern.hv_vmm_present: 0

Can you teach how to?

I tried

• Editing /EFI/config.plist (error => read-only filesystem)
• Use nvram (error => you must use recovery mode)
• Try to boot recovery mode (can't)

@dcontiveros

[dcontiveros]

I won't discuss specifics, as I don't run my macOS install via docker (rather just qemu it), but this patch worked for me:

https://forum.proxmox.com/threads/anyone-can-make-bluetooth-work-on-sonoma.153301/#post-697832

This did have the side effect of breaking OTA updates, so be sure to disable when prompted to update the OS.

[Alexey336]

I won't discuss specifics, as I don't run my macOS install via docker (rather just qemu it), but this patch worked for me:

https://forum.proxmox.com/threads/anyone-can-make-bluetooth-work-on-sonoma.153301/#post-697832

This did have the side effect of breaking OTA updates, so be sure to disable when prompted to update the OS.

This is worked on a sequoia, thank you!

[pcorezzola]

The problem is that there are new VM restrictions on utilizing iServices. You'll need a kernel patch for this. You need to ensure the following tunable is set to 0: kern.hv_vmm_present: 0

Can you teach how to?

I tried

• Editing /EFI/config.plist (error => read-only filesystem)
• Use nvram (error => you must use recovery mode)
• Try to boot recovery mode (can't)

@dcontiveros

1. Problem: EFI (Read-only)

There are two EFI partitions. One separate (read-only with OpenCore copy) and another next to the operating system (which is empty when mounted). We must mount both partitions using diskutil mount. Copy and paste the content into the empty EFI. As far as I know, when starting the operating system, it will first try to use the EFI partition next to the system (read/write) and if it fails or remains empty, it will use the "read-only" one. You can only edit the one next to the system. One method to verify if it's reading it is to edit the config.plist in the boot-args argument. Save and restart. Then in the terminal execute nvram boot-args, it should show what we wrote.

3. Problem: Accessing "Recovery Mode"

There is a selector menu when booting the operating system that is disabled by default. When we enable it, it will allow us to access "recovery mode" among other things. So, mount the EFI next to the Operating System and modify the config.plist. In the Misc -> Boot section, set PickerMode = Builtin and ShowPicker = True Save and restart.

2. Problem: Modifying NVRAM

If we try to modify the nvram from a terminal, it may throw an error. The solution is to use the terminal from "recovery mode" as I mentioned in the previous step.

Once we reach the terminal, we need to execute: csrutil disabled If it throws an error, execute "csrutil clear", restart, and repeat this step This disables the protection and will allow installing third-party kexts We can verify if protection is disabled by executing: csrutil status

I was able to solve each of the problems you mention, but unfortunately I cannot manage to disable the kern.hv_vmm_present parameter 😒 Theoretically, there is a kext called VMHide.kext, but I have not been able to install it correctly or it has had no effect.

[rafi16jan]

I won't discuss specifics, as I don't run my macOS install via docker (rather just qemu it), but this patch worked for me: https://forum.proxmox.com/threads/anyone-can-make-bluetooth-work-on-sonoma.153301/#post-697832 This did have the side effect of breaking OTA updates, so be sure to disable when prompted to update the OS.

This is worked on a sequoia, thank you!

With qemu or docker? Is there any detailed instructions for patching it with this docker image?

[kroese]

@rafi16jan That patch is already included in the latest image (v1.18) now

[mxcabre]

Sorry to bring this up again, but it's still not working for Sequoia. I'm still seeing the "An unknown error occurred" message, which prevents me from logging in. On Debian 12 (WSL2 latest update).