Hi. I am writing a little MDM application. Despite the basic task (add a password for 'remove profile' button in settings), it seems I am stuck with a problem: When I try to enroll my device with enrollment.mobileconfig file, Apple Configurator app, I receive an error The profile “Enrollment Profile” could not be installed because it is invalid. Make sure the profile is valid and try installing it again. The original architecture of my .mobileconfig contains of two payloads (com.apple.security.scep , com.apple.mdm), and it works correctly. However, when I try to add a third payload of com.apple.profileRemovalPassword , I receive the error stated above. From logs collected on iPhone, here's what was found : Failed to parse profile data. Error: NSError: Desc : The profile “Enrollment Profile” is invalid. Sugg : A profile containing an MDM payload must be removable. US Desc: The profile “Enrollment Profile” is invalid. US Sugg: A profile containing an MDM payload must be removable. Domain : MCProfileErrorDomain Code : 1000 Type : MCFatalError Params : ( "Enrollment Profile" ) ...Underlying error: NSError: Desc : A profile containing an MDM payload must be removable. US Desc: A profile containing an MDM payload must be removable. Domain : MCProfileErrorDomain Code : 1000 Type : MCFatalError Extra info: { isPrimary = 1; } My main dictionary contains HasRemovalPasscode Also, I have tried playing around with PayloadRemovalDisallowed setting it to true and false, however, I keep getting the same error message. There is also a second error produced: Profile MCConfigurationProfile, version 1: Display Name: “Enrollment Profile” Description : “***” Identifier : *** UUID : *** Organization: *** Is Stub : No Locked : Yes Removal passcode present Encrypted : No Trusted : 0 Signed : No Device Type : 0 Payloads: Payload MCSCEPPayload, version 1 Description : “***” Identifier : *** UUID : *** Type : com.apple.security.scep Display name: *** Organization: *** Payload MCMDMPayload, version 1 Description : “***” Identifier : *** UUID : *** Type : com.apple.mdm Organization: *** Payload MCRemovalPasswordPayload, version 1 Identifier : com.examp Can't parse profile: <decode: missing data> The code for com.apple.profileRemovalPassword is taken from apple documentation (https://developer.apple.com/documentation/devicemanagement/profileremovalpassword) I have also tried the automatic way - creating it from Apple Configurator, so it is correct in terms of syntax 100%. Several important notes: Creating a fresh new profile with just password removal protection single payload allows to perform a download of the profile If I comment out the whole com.apple.mdm payload block, I will be able to download this profile on iPhone also The com.apple.mdm block is also valid by itself, and works correctly I have tried implementing other types of "dummy" payloads - for example com.apple.dock <dict> <key>PayloadType</key> <string>com.apple.dock</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadIdentifier</key> <string>com.example.test.dock</string> <key>PayloadUUID</key> <string>22222222-3333-4444-5555-666666666666</string> <key>PersistentApps</key> <array/> </dict> And everything worked out fine. So my hypothetical conclusion out of these four notes might be in some type of interconnection between mdm and profileRemovalPassword, which isn't really listed anywhere? Or am I missing something ? Thank you in advance.

Hi. I have three disk partitions on my MacBook Air M1. The one with Monterey, the one with Sonoma, and the one with Sequoia (15.3.1 in particular). When I try to download the 15.4 Beta from software update in settings, everything would go "fine" - the download process is being completed, the computer says it's going to restart in 60seconds, the countdown begins, etc. However, when restarting several times, I am being logged in once again into previous macOS (15.3.1) version, with a kernel panic report. I had the same panic on macOS 15.3 when attempting to download 15.4 Beta. I've upgraded my macOS to 15.3.1, as I thought I'd need the very last available version of regular macOS to participate in the newest beta. However, the panic occurs, pointing to some t8020dart.c file. I don't even theoretically know what is this and couldn't find any reference to that C file. Attaching a part of panic report: panic(cpu 3 caller 0x0): t8020dart 0xfffffdf02c980000 (dart-disp0): Can't ignore lock validation @t8020dart.c:535 Debugger message: panic Memory ID: 0xff OS release type: Not set yet OS version: Not set yet Kernel version: Darwin Kernel Version 24.4.0: Sat Feb 15 22:43:38 PST 2025; root:xnu-11417.100.533.501.4~3/RELEASE_ARM64_T8103 Fileset Kernelcache UUID: 232D67A6D42C66E14780A24B3C0AE05D Kernel UUID: F2602757-A486-30A9-8D8E-714224E5FE4A Boot session UUID: 575CD5EA-6898-47ED-9AEC-05E318135695 iBoot version: iBoot-11881.100.964.0.1 iBoot Stage 2 version: iBoot-11881.100.964.0.1 secure boot?: YES roots installed: 0 Paniclog version: 14 KernelCache slide: 0x00000000181d8000 KernelCache base: 0xfffffe001f1dc000 Kernel slide: 0x00000000181e0000 Kernel text base: 0xfffffe001f1e4000 Kernel text exec slide: 0x00000000198d0000 Kernel text exec base: 0xfffffe00208d4000 mach_absolute_time: 0x85b39c4 Epoch Time: sec usec Boot : 0x00000000 0x00000000 Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x00000000 0x00000000 Zone info: Zone map: 0xfffffe120c000000 - 0xfffffe380c000000 . VM : 0xfffffe120c000000 - 0xfffffe17d8000000 . RO : 0xfffffe17d8000000 - 0xfffffe1a72000000 . GEN0 : 0xfffffe1a72000000 - 0xfffffe203e000000 . GEN1 : 0xfffffe203e000000 - 0xfffffe260a000000 . GEN2 : 0xfffffe260a000000 - 0xfffffe2bd6000000 . GEN3 : 0xfffffe2bd6000000 - 0xfffffe31a2000000 . DATA : 0xfffffe31a2000000 - 0xfffffe380c000000 Metadata: 0xfffffe76ce010000 - 0xfffffe76d7810000 Bitmaps : 0xfffffe76d7810000 - 0xfffffe76d8d80000 Extra : 0 - 0 CORE 0 recently retired instr at 0xfffffe0020a9d2d0 CORE 1 recently retired instr at 0xfffffe0020a9d2d0 CORE 2 recently retired instr at 0xfffffe0020a9d2d0 CORE 3 recently retired instr at 0xfffffe0020a9b9ec CORE 4 recently retired instr at 0xfffffe0020a9d2d0 CORE 5 recently retired instr at 0xfffffe0020a9d2d0 CORE 6 recently retired instr at 0xfffffe0020a9d2d0 CORE 7 recently retired instr at 0xfffffe0020a9d2d0 TPIDRx_ELy = {1: 0xfffffe2040392fb0 0: 0x0000000000000003 0ro: 0x0000000000000000 } CORE 0 PVH locks held: None CORE 1 PVH locks held: None CORE 2 PVH locks held: None CORE 3 PVH locks held: None CORE 4 PVH locks held: None CORE 5 PVH locks held: None CORE 6 PVH locks held: None CORE 7 PVH locks held: None CORE 0: PC=0xfffffe002102157c, LR=0xfffffe0021021568, FP=0xfffffebf22637890 CORE 1: PC=0xfffffe00210207a4, LR=0xfffffe0020fe4eb0, FP=0xfffffebf2262b890 CORE 2: PC=0xfffffe002094c790, LR=0xfffffe002094c63c, FP=0xfffffebf22643890 CORE 3 is the one that panicked. Check the full backtrace for details. CORE 4: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2213fed0 CORE 5: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf22163ed0 CORE 6: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2216fed0 CORE 7: PC=0xfffffe00209708b4, LR=0xfffffe00209708b4, FP=0xfffffebf2211bed0 Compressor Info: 0% of compressed pages limit (OK) and 0% of segments limit (OK) with 0 swapfiles and OK swap space Panicked task 0xfffffe260c042b78: 0 pages, 268 threads: pid 0: kernel_task Panicked thread: 0xfffffe2040392fb0, backtrace: 0xfffffebf22666920, tid: 279 lr: 0xfffffe00209332bc fp: 0xfffffebf226669b0 lr: 0xfffffe0020a93cdc fp: 0xfffffebf22666a20 lr: 0xfffffe0020a91e94 fp: 0xfffffebf22666ae0 lr: 0xfffffe00208dbb94 fp: 0xfffffebf22666af0 lr: 0xfffffe0020932ba0 fp: 0xfffffebf22666ec0 lr: 0xfffffe0020932924 fp: 0xfffffe0031577e90 lr: 0xfffffe00211cb198 fp: 0xfffffe0031577eb0 lr: 0xfffffe002120aae4 fp: 0xfffffe0031577f80 lr: 0xfffffe00211f9104 fp: 0xfffffe0031577fe0 lr: 0xfffffe00208dc3fc fp: 0xfffffebf22666ee0 lr: 0xfffffe0020a82d74 fp: 0xfffffebf22666f30 lr: 0xfffffe00222f9964 fp: 0xfffffebf22667c00 lr: 0xfffffe002107c198 fp: 0xfffffebf22667c90 lr: 0xfffffe002107b79c fp: 0xfffffebf22667dc0 lr: 0xfffffe002107963c fp: 0xfffffebf22667e40 lr: 0xfffffe002107ffc8 fp: 0xfffffebf22667f20 lr: 0xfffffe00208e4f04 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleT8020DART(1.0)[6BE1928B-115D-345C-B457-FD1101FC7E1E]@0xfffffe00222f9120->0xfffffe002230139b dependency: com.apple.driver.AppleARMPlatform(1.0.2)[4EB15554-31E0-3057-9A85-EAA79C69E848]@0xfffffe0021369200->0xfffffe00213bf21f dependency: com.apple.driver.IODARTFamily(1)[8FC5A69F-6052-3F02-9EA3-78D080116812]@0xfffffe0022ec6750->0xfffffe0022eda9cf last started kext at 139867172: com.apple.plugin.IOgPTPPlugin 1340.12 (addr 0xfffffe001fba3f70, size 139368)

Hi. I am facing a panic in distributed virtual filesystem of my own making. The panic arises on attempt of copying a large folder, or writing a large file (both around 20gb). An important note here is that the amount of files we try to copy is larger than available space (for testing purposes, the virtual file system had a capacity of 18 gigabytes). The panic arises somewhere on 12-14gigabytes deep into copying. On the moment of panic, there are still several gigabytes of storage left. The problem is present for sure for such architectures and macOS versions: Sonoma 14.7.1 arm64e Monterey 12.7.5 arm64e Ventura 13.7.1 intel Part from panic log from Ventura 13.7.1 intel, with symbolicated addresses: panic(cpu 2 caller 0xffffff80191a191a): watchdog timeout: no checkins from watchdogd in 90 seconds (48 total checkins since monitoring last enabled) Panicked task 0xffffff907c99f698: 191 threads: pid 0: kernel_task Backtrace (CPU 2), panicked thread: 0xffffff86e359cb30, Frame : Return Address 0xffffffff001d7bb0 : 0xffffff8015e70c7d mach_kernel : _handle_debugger_trap + 0x4ad 0xffffffff001d7c00 : 0xffffff8015fc52e4 mach_kernel : _kdp_i386_trap + 0x114 0xffffffff001d7c40 : 0xffffff8015fb4df7 mach_kernel : _kernel_trap + 0x3b7 0xffffffff001d7c90 : 0xffffff8015e11971 mach_kernel : _return_from_trap + 0xc1 0xffffffff001d7cb0 : 0xffffff8015e70f5d mach_kernel : _DebuggerTrapWithState + 0x5d 0xffffffff001d7da0 : 0xffffff8015e70607 mach_kernel : _panic_trap_to_debugger + 0x1a7 0xffffffff001d7e00 : 0xffffff80165db9a3 mach_kernel : _panic_with_options + 0x89 0xffffffff001d7ef0 : 0xffffff80191a191a com.apple.driver.watchdog : IOWatchdog::userspacePanic(OSObject*, void*, IOExternalMethodArguments*) (.cold.1) 0xffffffff001d7f20 : 0xffffff80191a10a1 com.apple.driver.watchdog : IOWatchdog::checkWatchdog() + 0xd7 0xffffffff001d7f50 : 0xffffff80174f960b com.apple.driver.AppleSMC : SMCWatchDogTimer::watchdogThread() + 0xbb 0xffffffff001d7fa0 : 0xffffff8015e1119e mach_kernel : _call_continuation + 0x2e Kernel Extensions in backtrace: com.apple.driver.watchdog(1.0)[BD08CE2D-77F5-358C-8F0D-A570540A0BE7]@0xffffff801919f000->0xffffff80191a1fff com.apple.driver.AppleSMC(3.1.9)[DD55DA6A-679A-3797-947C-0B50B7B5B659]@0xffffff80174e7000->0xffffff8017503fff dependency: com.apple.driver.watchdog(1)[BD08CE2D-77F5-358C-8F0D-A570540A0BE7]@0xffffff801919f000->0xffffff80191a1fff dependency: com.apple.iokit.IOACPIFamily(1.4)[D342E754-A422-3F44-BFFB-DEE93F6723BC]@0xffffff8018446000->0xffffff8018447fff dependency: com.apple.iokit.IOPCIFamily(2.9)[481BF782-1F4B-3F54-A34A-CF12A822C40D]@0xffffff80188b6000->0xffffff80188e7fff Process name corresponding to current thread (0xffffff86e359cb30): kernel_task Boot args: keepsyms=1 Mac OS version: 22H221 Kernel version: Darwin Kernel Version 22.6.0: Thu Sep 5 20:48:48 PDT 2024; root:xnu-8796.141.3.708.1~1/RELEASE_X86_64 The origin of the problem is surely inside my filesystem. However, the panic happens not there but somewhere in watchdog. As far as I can tell, the source code for watchdog is not available for public. I can't understand what causes the panic. Let's say we have run out of space. Couldn't write data. Writing received a proper error message and aborted. That's what is expected. However, it is unclear for why the panic arises.

Hi. I am developing a custom virtual file system and facing such behaviour: Upon using some graphical apps, for example Adobe Media Encoder, attempting to navigate inside my filesystem deeper than root folder will fail - nothing will happen on "double click" on that subfolder. Another problem, is that whether I try to re-navigate into root directory, it will be empty. The problem is not present for most GUI apps - for example navigation inside Finder, upon choosing download path for file in Safari, apps like Microsoft Word, Excel and other range of applications work totally correctly. A quick note here. From what I have seen - all apps that work correctly actually have calls to VFS_VGET - a predefined vfs layer hook. Whether the Adobe Media Encoder does not call for it - neither in my filesystem, nor in Samba, so my guess is that some applications have different browsing and retrieving algorithm. Is there anything I should examine further ? Default routines (vnop_open, vnop_lookup, vnop_readdir, vnop_close) behave as expected, without any errors. P.S. This application (Adobe Media Encoder) works properly on Samba.

I'm writing a virtual file system as my educational project (generic kernel extension). Currently, mostly everything is implemented, however, I'm having trouble using Finder search and tags. The results simply don't show up - despite I am having vnop_... calls to those files. The extended attributes are supported. Inodes are stable. Mmap is implemented. Vnop_ioctl returns KERN_SUCCESS (but no implementation). An important moment: Previously, the search didn't work at all. Researching the web has shown me, that Spotlight indexation and Finder search are tightly glued. So basically I was trying to enable support for spotlight, thinking that would be the source of the problem. I was receiving "Unknown indexing state". All those tricks with mdutil, launchd, manual and reindexation either were doing nothing or returning error. The problem was resolved FOR SONOMA by making by VFS appear as local one (adding flags for MNT_LOLCAL and MNT_DOVOLFS). This has changed the state from Unknown indexing state for spotlight to Indexing is disabled. No need to turn it on for me - I am interested only in search and tags, not the spotlight itself. Basically, whether spotlight recognises my driver as no-error, the Finder works correctly, even with indexation disabled. Whether on Monterey*, or Ventura, I get the same problem. However, neither system logs nor my driver show any kinds of errors. The spotlight simply returns error. Reindexation attempt via Security&Privacy returns "Unknown error occured". The metadata for Ventura and Monterey read attempt (mdls) returns "Unable to locate file", however returns a huge list for Sonoma. *Monterey and Ventura never have .Spotlight-V100 folder. No disable indexing files or other spotlight restrictions are present. No user space solutions seem to help. The kext is unsigned and running in an environment with SIP disabled and Security Mode reduced to Permissive. Maybe there some abstract rules for what is required on VFS side to be recognised okay'ish by Spotlight ? Or maybe something specific right for my case ? Any pointers and/or assistance would be greatly appreciated.