configure fails with "error: XCode tool 'metal' neither found in path nor with xcrun" for ports that require the Metal toolchain on macOS 26 Tahoe

[kwolcott]

:info:configure checking for metal... [not found]
:info:configure checking if metal can be run using xcrun... no
:info:configure configure: error: XCode tool 'metal' neither found in path nor with xcrun
:info:configure configure exiting with result code 1

[reneeotten (Renee Otten)]

in the future, please add the port maintainer(s) to CC when you open a ticket.

[reneeotten (Renee Otten)]

See wiki:TahoeProblems#MetaltoolchainisnolongerbundledinXcode

[breun (Nils Breunese)]

Replying to reneeotten:

See wiki:TahoeProblems#MetaltoolchainisnolongerbundledinXcode

I ran xcodebuild -downloadComponent MetalToolchain to install the Metal toolchain, but after that I still get the same error when I try to sudo port install openjdk21. Did it work for you, Renee?

[breun (Nils Breunese)]

By the way, I see the same error for openjdk17 and openjdk24 on macOS Tahoe. I haven't tried all other openjdk* ports yet.

[reneeotten (Renee Otten)]

Replying to breun:

Replying to reneeotten:

See wiki:TahoeProblems#MetaltoolchainisnolongerbundledinXcode

I ran xcodebuild -downloadComponent MetalToolchain to install the Metal toolchain, but after that I still get the same error when I try to sudo port install openjdk21. Did it work for you, Renee?

I didn't try for openjdk21 but for qt6-qtwebengine. It didn't work there either even though according to the description(s) I've found so far it should work. It certainly installed the Metal toolchain; not sure why xcrun seems unable to find it...

[breun (Nils Breunese)]

xcrun does seem able to find metal when I try to run it myself:

❯ xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.MYC1Jn/Metal.xctoolchain/usr/metal/current/bin

[reneeotten (Renee Otten)]

Replying to breun:

xcrun does seem able to find metal when I try to run it myself:

Same here:

> xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /Users/renee/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965/Metal.xctoolchain/usr/metal/current/bin

what I find a bit surprising/weird is the InstalledDir but I'm not sure where the the toolchains should go...

[ryandesign (Ryan Carsten Schmidt)]

​https://stackoverflow.com/questions/79660070/xcode-26-metal-compiler-error-metaltoolchain

[ryandesign (Ryan Carsten Schmidt)]

I've run xcodebuild -downloadComponent MetalToolchain on the macOS 26 arm64 buildbot worker, verified xcrun metal --version now works, and scheduled rebuilds for some openjdk ports to see what happens there.

[ryandesign (Ryan Carsten Schmidt)]

So far openjdk21 and openjdk17 built successfully, so at least we'll have binaries available for you soon even if you can't build it on your own system.

[breun (Nils Breunese)]

Replying to ryandesign:

So far openjdk21 and openjdk17 built successfully, so at least we'll have binaries available for you soon even if you can't build it on your own system.

Great! But any ideas why xcodebuild -downloadComponent MetalToolchain made this work on the buildbot, but not on my machine?

[breun (Nils Breunese)]

I did notice that in a new terminal the InstalledDir now shows differently:

❯ xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.MYC1Jn/Metal.xctoolchain/usr/metal/current/bin

But openjdk17 and openjdk21 still fail with the same error on my machine:

:info:configure checking for metal... [not found]
:info:configure checking if metal can be run using xcrun... no
:info:configure configure: error: XCode tool 'metal' neither found in path nor with xcrun

[kwolcott]

Still fails for me.

[breun (Nils Breunese)]

Replying to ryandesign:

So far openjdk21 and openjdk17 built successfully, so at least we'll have binaries available for you soon even if you can't build it on your own system.

Which user installs the Metal toolchain on the buildbots? It is the same user that builds the port?

I found that after xcodebuild -downloadComponent MetalToolchain I can successfully run xcrun metal --version using my normal daily user account:

❯ xcodebuild -downloadComponent MetalToolchain
Beginning asset download...
Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg
Done downloading: Metal Toolchain 17A324.
❯ xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.MYC1Jn/Metal.xctoolchain/usr/metal/current/bin

But if I try to run xcrun metal --version as another user, like root, then that fails:

❯ xcodebuild -downloadComponent MetalToolchain
Beginning asset download...
Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg
Done downloading: Metal Toolchain 17A324.
❯ sudo su -
# xcrun metal --version
error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

[ryandesign (Ryan Carsten Schmidt)]

Replying to breun:

Which user installs the Metal toolchain on the buildbots?

I was logged in as the buildbot user, which is the normal user account I created when installing macOS.

It is the same user that builds the port?

No, mpbb installs ports using sudo port install so they start as root and then drop privileges to the macports user.

I found that after xcodebuild -downloadComponent MetalToolchain I can successfully run xcrun metal --version using my normal daily user account:

But if I try to run xcrun metal --version as another user, like root, then that fails:

Both work for me.

[reneeotten (Renee Otten)]

I see the same as Nils, running it as a different user fails.

To me it seems the issue is that in that case I get:

root# xcrun -f metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

when I run it as my "normal" user, I get:

> xcrun -f metal
/Users/renee/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965/Metal.xctoolchain/usr/bin/metal

Running the former as "normal" user gives, as expected, the usual error message:

> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

@Ryan: does the file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal exist on the buildbot?

[markmentovai (Mark Mentovai)]

Is there any improvement if you run xcodebuild -downloadComponent MetalToolchain as the user that will be running xcrun metal? Even if you’ve already run xcodebuild -downloadComponent MetalToolchain as a different user, try this.

And if you still have trouble, try removing the xcrun_db cache, which is normally in ${TMPDIR}/xcrun_db, bearing in mind that each user may have their own ${TMPDIR}. Alternatively, you can test with xcodebuild -find metal in place of xcrun --find metal, as xcodebuild -find avoids xcrun’s cache.

What I’m finding so far is that the system downloads the toolchain dmg once for all users, to /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/*.asset/AssetData/Restore/*.dmg. It also only wants to mount this dmg once. The systemwide mount point would be /var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-* which is supervised by /usr/libexec/cryptexd and should be accessible to all users, but there also seems to be the possibility of winding up with a cryptexd-free mount in a user’s home directory, ~/Library/Developer/DVTDownloads/MetalToolchain/mounts/*. The first one to mount seems to win, so if the .dmg gets mounted in a way that’s visible only to one user (~/Library is normally not readable by others), it will block others from accessing it, at least until unmounted. Furthermore, it may be the case that a user that hasn’t run xcodebuild -downloadComponent MetalToolchain won’t even try to look for or mount it.

Some of these details are a little sketchy and “raw lab notes” so far, but maybe there’s something here that’s helpful.

[ryandesign (Ryan Carsten Schmidt)]

Replying to reneeotten:

@Ryan: does the file /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal exist on the buildbot?

% ls -l /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
-rwxr-xr-x  1 buildbot  staff  107552 Sep 11 08:59 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

[markmentovai (Mark Mentovai)]

I’m seeing this problem in a more serious way on one computer (which happens to be x86_64) than on another (which happens to be arm64). I don‘t know that the architecture difference is definitely responsible for the behavior difference.

On x86_64, starting with the .dmg unmounted, when I run xcodebuild -find metal, xcodebuild logs this to the Console:

Attempt 0: Failed to mount Optional(file:///System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/): 17A324 with tatsu, alwaysPersonalize = false, error = Error Domain=DVTCryptexErrorDomain Code=2 "Personalization attempt failed with error: Error Domain=com.apple.security.cryptex Code=5 "Customer Metal Toolchain: Personalization failed" UserInfo={NSLocalizedDescription=Customer Metal Toolchain: Personalization failed, NSUnderlyingError=0x600002ba0270 {Error Domain=com.apple.security.cryptex.posix Code=19 "Customer Metal Toolchain: failed to copy nonce from domain [19: Operation not supported by device]" UserInfo={NSLocalizedDescription=Customer Metal Toolchain: failed to copy nonce from domain [19: Operation not supported by device]}}}" UserInfo={NSLocalizedDescription=Personalization attempt failed with error: Error Domain=com.apple.security.cryptex Code=5 "Customer Metal Toolchain: Personalization failed" UserInfo={NSLocalizedDescription=Customer Metal Toolchain: Person

The ENODEV is probably coming from graftdmg, which is a private system call involved in mounting cryptexes.

The toolchain is not mounted at cryptexd’s mount point, so it falls back to mounting in ~/Library if at all. From there, it won’t be accessible to other users.

[markmentovai (Mark Mentovai)]

I’ve done some controlled virtual machine testing on mac-arm64, macOS 26.0 25A354 with Xcode 26.0.1 17A400, and have found a crucial difference that makes xcodebuild -find metal work for some users and not for others: the presence of ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist. This .plist currently contains an 11-element array with entries like:

        <dict>
                <key>affinity</key>
                <string>available</string>
                <key>assetBuildUpdate</key>
                <string>17A324</string>
                <key>assetType</key>
                <string>metalToolchain</string>
                <key>xcodeBuildUpdate</key>
                <string>17A400</string>
        </dict>

This maps Xcode 17A400 (xcodeBuildUpdate) to use version 17A324 (assetBuildUpdate) of the Metal toolchain (assetType). If this file is absent from the user’s ~/Library, or the array doesn’t contain an element whose xcodeBuildUpdate matches Xcode’s build version, xcodebuild -find and thus xcrun won’t be able to find the Metal toolchain, even if installed.

This .plist is maintained by Xcode, and will be put in place for a user when any of the following are run as that user:

• When Xcode.app (the UI) is launched.
• When xcodebuild -downloadComponent MetalToolchain is used, even if the toolchain has already been downloaded and installed.
• When xcodebuild -showComponent MetalToolchain is used and the Metal toolchain has already been downloaded.

Sadly, Xcode does not appear to respect this .plist if placed at the root /Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist. The .plist must be in the ~/Library of any user that wishes to use the Metal toolchain via xcodebuild or xcrun.

For ports that require the Metal toolchain, it ought to be sufficient to run xcodebuild -showComponent MetalToolchain as a pre-configure step to ensure that the required .plist is in place. This won’t download or install anything, but if the Metal toolchain is already present on the system (because any user had previously run xcodebuild -downloadComponent MetalToolchain or added the component in Xcode.app’s UI at Xcode:Settings…:Components:Other Components:Metal Toolchain:[Get]), it’ll ensure that it’s findable.

mark@axilla zsh% xcodebuild -deleteComponent MetalToolchain
Removed: 17A324.
mark@axilla zsh% xcodebuild -find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
mark@axilla zsh% xcodebuild -downloadComponent MetalToolchain
Beginning asset download...
Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg
Done downloading: Metal Toolchain 17A324.
mark@axilla zsh% xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.N0teuK/Metal.xctoolchain/usr/bin/metal
mark@axilla zsh% su newuser
Password:
newuser@axilla zsh% rm -f ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist
newuser@axilla zsh% xcodebuild -find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
newuser@axilla zsh% xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.N0teuK
newuser@axilla zsh% xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.N0teuK/Metal.xctoolchain/usr/bin/metal

I believe that it’s a bug for xcodebuild -find to not place this .plist on its own when asked to find a tool in the Metal toolchain, and I’ll be filing that bug report with Apple.

I don’t think that this addresses the full extent of the problem. In particular, my discoveries in #comment:21 regarding alternate mount points not accessible to all users (such as in #comment:7, and perhaps x86_64-associated) are concerning. But this should at least be a good start, and address some of the problems raised here, such as #comment:14, #comment:15, and #comment:16.

[breun (Nils Breunese)]

Wow, nice detective work, Mark!

Do you believe it's safe for ports that need Metal to build to always execute xcodebuild -showComponent MetalToolchain in pre-configure or will this fail on older macOS versions?

Maybe it would even be a good idea to create a PortGroup for ports that need Metal?

[markmentovai (Mark Mentovai)]

I filed FB20389216 (​OpenRadar copy) to cover #comment:22.

Replying to breun:

Wow, nice detective work, Mark!

Thanks!

Do you believe it's safe for ports that need Metal to build to always execute xcodebuild -showComponent MetalToolchain in pre-configure or will this fail on older macOS versions?

It’s about Xcode version, not macOS version.

It’s harmless to run xcodebuild -showComponent MetalToolchain if its exit status is ignored. It’ll produce a bit of output on stderr that will clutter the log, however.

There are 3 main possibilities:

1. Xcode ≥ 26 with the Metal toolchain installed. The Metal toolchain is usable.

mark@axilla zsh% xcodebuild -version
Xcode 26.0.1
Build version 17A400
mark@axilla zsh% xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.N0teuK
mark@axilla zsh% echo $?
0
mark@axilla zsh% xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.N0teuK/Metal.xctoolchain/usr/metal/current/bin

2. Xcode ≥ 26 with the Metal toolchain not installed. xcodebuild -downloadComponent MetalToolchain will need to be run in order to materialize a usable Metal toolchain.

mark@axilla zsh% xcodebuild -version
Xcode 26.0.1
Build version 17A400
mark@axilla zsh% xcodebuild -showComponent MetalToolchain
Build Version: 17A324
Status: uninstalled
mark@axilla zsh% echo $?
0
mark@axilla zsh% xcrun metal --version
error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

3. Xcode < 26, with a bundled Metal toolchain. The Metal toolchain is usable.

mark@axilla zsh% DEVELOPER_DIR=…/Xcode_16.4.app xcodebuild -version
Xcode 16.4
Build version 16F6
mark@axilla zsh% DEVELOPER_DIR=…/Xcode_16.4.app xcodebuild -showComponent MetalToolchain
2025-09-26 11:32:19.489 xcodebuild[5265:299942] Writing error result bundle to /var/folders/…/T/ResultBundle_2025-26-09_11-32-0019.xcresult
xcodebuild: error: invalid option '-showComponent'

Usage: xcodebuild [-project <projectname>] [[-target <targetname>]...|-alltargets] [-configuration <configurationname>] [-arch <architecture>]... [-sdk [<sdkname>|<sdkpath>]] [-showBuildSettings [-json]] [<buildsetting>=<value>]... [<buildaction>]...
[…]
    -create-xcframework                                      create an xcframework from prebuilt libraries; -help for more information.
mark@axilla zsh% echo $?
64
mark@axilla zsh% DEVELOPER_DIR=~/Downloads/Xcode_16.4.app xcrun metal --version
Apple metal version 32023.620 (metalfe-32023.620)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /Users/mark/Downloads/Xcode_16.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/metal/current/bin

Maybe it would even be a good idea to create a PortGroup for ports that need Metal?

Possibly. Perhaps that could also provide a more front-and-center error message about obtaining the Metal toolchain if it’s not installed than the error message buried in the log.

[ryandesign (Ryan Carsten Schmidt)]

So how to explain that it worked on the buildbot when ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist does not exist in the macports user's home?

[markmentovai (Mark Mentovai)]

Applying the above to the cross-user-mount problem that I see on mac-x86_64:

user1@eightysix zsh% rm -f ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist

user1@eightysix zsh% xcodebuild -find metal                  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

user1@eightysix zsh% xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /Users/user1/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965

The mount point within ~user1 is the first indication of a problem. ~user1/Library is not accessible to others, such as user2:

user1@eightysix zsh% ls -ld ~/Library
drwx------@ 104 user1  staff  3328 Sep 15 20:04 /Users/user1/Library

But the Metal toolchain is now usable for user1:

user1@eightysix zsh% xcodebuild -find metal
/Users/user1/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965/Metal.xctoolchain/usr/bin/metal

user1@eightysix zsh% xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /Users/user1/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965/Metal.xctoolchain/usr/metal/current/bin

Try user2:

user1@eightysix zsh% su user2
Password:

user2@eightysix zsh% rm -f ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist

user2@eightysix zsh% xcodebuild -find metal                  
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

user2@eightysix zsh% xcodebuild -showComponent MetalToolchain
2025-09-26 11:53:16.414 xcodebuild[6859:1375971]  IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.
2025-09-26 11:53:16.417 xcodebuild[6859:1375970]  IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Search Path: /Users/user1/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965

xcodebuild -showComponent MetalToolchain is able to resolve the mount point in ~user1/Library, but user2 has no permission to traverse the path to it beyond that point, hence IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.

The Metal toolchain remains unusable for user2, who’s given the path to the unusable metal driver in Xcode.app from xcodebuild -find metal. This stub just asks you to download the Metal toolchain.

user2@eightysix zsh% xcodebuild -find metal                  
2025-09-26 11:53:23.408 xcodebuild[6872:1376163]  IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.
2025-09-26 11:53:23.410 xcodebuild[6872:1376187]  IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

user2@eightysix zsh% xcrun metal --version 
error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

And, of course, following the suggested remediation instructions doesn’t work: xcodebuild -downloadComponent works no better than xcodebuild -showComponent.

user2@eightysix zsh% xcodebuild -downloadComponent MetalToolchain
2025-09-26 11:59:16.819 xcodebuild[6932:1379718]  IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.
Beginning asset download...
2025-09-26 11:59:17.224 xcodebuild[6932:1379717]  IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.
Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData/Restore/022-17211-415.dmg
Done downloading: Metal Toolchain 17A324.

user2@eightysix zsh% xcodebuild -find metal
2025-09-26 12:00:28.760 xcodebuild[6939:1380374]  IDEDownloadableMetalToolchainCoordinator: Failed to remount the Metal Toolchain: The file “4ab058bc1c53034b8c0a9baca6fba2d2b78bb965” couldn’t be opened because you don’t have permission to view it.
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

user2@eightysix zsh% xcrun metal --version
error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

[reneeotten (Renee Otten)]

Yep, Mark - that's the exact same problem I'm having on x86_64... and unfortunately I am totally out of my league with this :( Thanks for all your work on this and hopefully someone (yes, you Apple) will come up with a fix!

[markmentovai (Mark Mentovai)]

Replying to reneeotten:

Yep, Mark - that's the exact same problem I'm having on x86_64... and unfortunately I am totally out of my league with this :( Thanks for all your work on this and hopefully someone (yes, you Apple) will come up with a fix!

Renee, my x86_64 workaround acknowledges that only one user can have the Metal toolchain cryptex mounted at a time. If you can accept this limitation, just unmount it for the user that won’t be using it.

user1@eightysix zsh% xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /Users/user1/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965

user1@eightysix zsh% diskutil eject $(xcodebuild -showComponent MetalToolchain | sed -E -n -e 's/^Toolchain Search Path: (.*)$/\1/p')
Disk /Users/user1/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965 ejected

user1@eightysix zsh% su user2
Password:

user2@eightysix zsh% xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /Users/user2/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965

user2@eightysix zsh% xcodebuild -find metal
/Users/user2/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965/Metal.xctoolchain/usr/bin/metal

user2@eightysix zsh% xcrun --find metal
/Users/user2/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965/Metal.xctoolchain/usr/bin/metal

user2@eightysix zsh% xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /Users/user2/Library/Developer/DVTDownloads/MetalToolchain/mounts/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965/Metal.xctoolchain/usr/metal/current/bin

And now you’re good to go.

I don’t really think that this is something that port would be able to do on the user’s behalf. I wouldn’t want to “steal” the toolchain away from another user that might be using it. But it could be suggested as a possible remediation if the bug is experienced.

Since you’ve confirmed seeing this on x86_64, I’ll file another bug report with Apple about this problem, independent of FB20389216.

[markmentovai (Mark Mentovai)]

Replying to ryandesign:

So how to explain that it worked on the buildbot when ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist does not exist in the macports user's home?

Previously, in #comment:9, you said:

I've run xcodebuild -downloadComponent MetalToolchain on the macOS 26 arm64 buildbot worker, verified xcrun metal --version now works, and scheduled rebuilds for some openjdk ports to see what happens there.

If you ran xcodebuild -downloadComponent MetalToolchain as the macports user, it should have set up ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist at that time. No?

Regardless, xcodebuild -downloadComponent MetalToolchain is one of the three things I identified in #comment:22 that you can do as a user to make the Metal toolchain work for that user.

[ryandesign (Ryan Carsten Schmidt)]

Replying to markmentovai:

Replying to ryandesign:

So how to explain that it worked on the buildbot when ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist does not exist in the macports user's home?

Previously, in #comment:9, you said:

I've run xcodebuild -downloadComponent MetalToolchain on the macOS 26 arm64 buildbot worker, verified xcrun metal --version now works, and scheduled rebuilds for some openjdk ports to see what happens there.

If you ran xcodebuild -downloadComponent MetalToolchain as the macports user, it should have set up ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist at that time. No?

I didn't run it as the macports user. I ran it in while logged in with the regular user account that was created during macOS post-installation setup, which on that machine is called buildbot.

[ryandesign (Ryan Carsten Schmidt)]

macOS is still logged in to the buildbot account while mpbb is having MacPorts install ports. Maybe that's why it works. Are other people also finding that installing the toolchain in their regular account allows MacPorts to see it?

[markmentovai (Mark Mentovai)]

The independent x86-64 bug from #comment:21, #comment:26, and #comment:27 is filed as FB20390263 (​OpenRadar copy).

[markmentovai (Mark Mentovai)]

Replying to ryandesign:

macOS is still logged in to the buildbot account while mpbb is having MacPorts install ports. Maybe that's why it works. Are other people also finding that installing the toolchain in their regular account allows MacPorts to see it?

I’m mostly ignoring the xcrun cache (normally ${TMPDIR}/xcrun_db) for this investigation, but I suppose this could also be related to that cache if, say, the buildbot and macports users are sharing it, and the builds are only trying to access metal and metallib via xcrun (the expected situation).

[reneeotten (Renee Otten)]

Replying to ryandesign:

macOS is still logged in to the buildbot account while mpbb is having MacPorts install ports. Maybe that's why it works. Are other people also finding that installing the toolchain in their regular account allows MacPorts to see it?

No, that's the whole point of this thread ;) Running xcodebuild -downloadComponent MetalToolchain in the regular user account does *not* allow MacPorts to see it. But again, I can only do that on x86_64 so that might be a separate issue; likely with the mount as shown in comment:28.

Are you planning to set-up a x86_64 Tahoe buildbod as well; the issue should remain there I would think.

[markmentovai (Mark Mentovai)]

Replying to ryandesign:

macOS is still logged in to the buildbot account while mpbb is having MacPorts install ports. Maybe that's why it works.

I didn’t find that which user was logged in to the UI made any difference.

I guess the buildbot succeeded for mac-arm64 ​in this build, but I don’t see any logs there to be able to dig into how it was able to succeed any further. I’m interested in figuring it out, though. main.log and config.log could be useful. A look at other contents of ~mpbb might be, too. And what do xcodebuild -find metal and xcrun --find metal show, both as your buildbot and mpbb users?

I did try this locally, and unsurprisingly, the user macports which has never run Xcode.app, xcodebuild -downloadComponent MetalToolchain, or xcodebuild -showComponent MetalToolchain, is unable to port -s install openjdk21:

admin@axilla zsh% sudo port -s install openjdk21
--->  Computing dependencies for openjdk21
--->  Fetching distfiles for openjdk21
--->  Attempting to fetch openjdk-21.0.8-ga.tar.xz from https://distfiles.macports.org/openjdk21
--->  Verifying checksums for openjdk21                                         
--->  Extracting openjdk21
--->  Applying patches to openjdk21
--->  Configuring openjdk21
Error: Failed to configure openjdk21: consult /opt/local/var/macports/build/openjdk21-42c1353a/work/jdk-21.0.8+9/config.log
Error: Failed to configure openjdk21: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk21/openjdk21/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port openjdk21 failed

/opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk21/openjdk21/main.log shows the same error as the ​attachment on this bug:

:debug:configure configure phase started at Fri Sep 26 14:19:54 EDT 2025
:notice:configure --->  Configuring openjdk21
:debug:configure Preferred compilers: clang macports-clang-18 macports-clang-17
:debug:configure Using compiler 'Xcode Clang'
[…]
:info:configure checking for install_name_tool... /usr/bin/install_name_tool
:info:configure checking for metal... [not found]
:info:configure checking if metal can be run using xcrun... no
:info:configure configure: error: XCode tool 'metal' neither found in path nor with xcrun
:info:configure configure exiting with result code 1
:info:configure Command failed:  cd "/opt/local/var/macports/build/openjdk21-42c1353a/work/jdk-21.0.8+9" && /opt/local/bin/bash configure --prefix=/opt/local/Library/Java --with-debug-level=release --with-native-debug-symbols=none --with-version-string=21.0.8+9 --with-sysroot=`xcrun --sdk macosx --show-sdk-path` --with-extra-cflags="-Os" --with-extra-cxxflags="-Os -stdlib=libc++" --with-extra-ldflags="-L/opt/local/lib -Wl,-headerpad_max_install_names" --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk-21-azul-zulu.jdk/Contents/Home --with-freetype=system --with-freetype-include=/opt/local/include/freetype2 --with-freetype-lib=/opt/local/lib --disable-warnings-as-errors --disable-precompiled-headers --with-vendor-name="MacPorts" --with-vendor-url="https://www.macports.org" --with-vendor-bug-url="https://trac.macports.org/newticket?port=openjdk21" --with-vendor-vm-bug-url="https://trac.macports.org/newticket?port=openjdk21" --with-conf-name=release --with-debug-level=release --with-jvm-variants=server 
:info:configure Exit code: 1
:error:configure Failed to configure openjdk21: consult /opt/local/var/macports/build/openjdk21-42c1353a/work/jdk-21.0.8+9/config.log
:error:configure Failed to configure openjdk21: configure failure: command execution failed
:debug:configure Error code: NONE
:debug:configure Backtrace: configure failure: command execution failed
:debug:configure     while executing
:debug:configure "$procedure $targetname"
:error:configure See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk21/openjdk21/main.log for details.

[markmentovai (Mark Mentovai)]

I anticipate an additional problem when the MetalToolchain cryptex is mounted beneath /private/var/run/com.apple.security.cryptexd/mnt/, which is where cryptexd will normally put it. On a reasonably fresh mac-arm64 macOS 26.0 25A354 system, with Xcode 26.0.1 17A400 and the Metal toolchain 17A324:

mark@axilla zsh% ls -ldfT / /private /private/var /private/var/run /private/var/run/com.apple.security.cryptexd /private/var/run/com.apple.security.cryptexd/mnt /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1 /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain/usr /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain/usr/bin /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain/usr/bin/metal
drwxr-xr-x  22 root  wheel      704 Sep  9 03:15:49 2025 /
drwxr-xr-x   6 root  wheel      192 Sep 25 23:32:36 2025 /private
drwxr-xr-x  35 root  wheel     1120 Sep 18 11:57:00 2025 /private/var
drwxrwxr-x  34 root  daemon    1088 Sep 26 15:31:06 2025 /private/var/run
drwx---r-x   8 root  daemon     256 Sep 25 23:32:38 2025 /private/var/run/com.apple.security.cryptexd
drwxr-xr-x   3 root  daemon      96 Sep 25 23:33:35 2025 /private/var/run/com.apple.security.cryptexd/mnt
drwxr-xr-x   4 root  wheel      128 Aug  8 22:54:49 2025 /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1
drwxr-xr-x   4 root  wheel      128 Aug  8 22:54:49 2025 /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain
drwxr-xr-x   5 root  wheel      160 Aug  8 22:54:49 2025 /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain/usr
drwxr-xr-x  54 root  wheel     1728 Aug  8 22:54:49 2025 /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain/usr/bin
-rwxr-xr-x   1 root  wheel   238624 Aug  8 22:54:49 2025 /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.5Np0u1/Metal.xctoolchain/usr/bin/metal

/private/var/run/com.apple.security.cryptexd is mode 0o705 (rwx---r-x), root:daemon. As long as you’re not in group daemon, you can access this just fine. Who’s in group daemon? Normally it’s just root, and root has access because root is the owner (and has permission), and because root is uid 0 (and is special).

The problem is that when MacPorts is invoked via something like sudo port install openjdk21, when configured to drop privileges, port will run the build as another user, such as macports. In doing so, the switch from root to macports will adjust the effective user ID (euid), real user ID (uid), effective [primary] group ID (egid), and real [primary] group ID (gid). I don’t think any mind is paid to the supplemental group list. The supplemental group list in effect for root, when sudo port was run, will remain in effect even when port drops privileges to the MacPorts user. Thus, the unprivileged port process remains a member of group daemon, and is denied access to /private/var/run/com.apple.security.cryptexd or anything contained therein. To overcome this, MacPorts will need to make an initgroups (best) or setgroups (acceptable) call to reinitialize the supplemental group list to something appropriate for the unprivileged user.

In general, this means that operations done as the MacPorts user, which are expected to be done with least privilege, are actually carrying more privilege than anticipated or appropriate, in the form of root’s supplemental group list. These operations retain other group memberships as well including wheel, kmem, tty, admin, and more. Even absent the Metal Toolchain concern, this is certainly a bug worth fixing.

[markmentovai (Mark Mentovai)]

The problem described by comment:22, comment:24, and ​FB20389216 seems to be fixed in Xcode 26.1b1 17B5025f: xcodebuild -find metal is able to find the Metal toolchain even when ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist isn’t present.

user1@axilla zsh% sudo xcode-select --switch /Applications/Xcode-beta.app

user1@axilla zsh% xcodebuild -version
Xcode 26.1
Build version 17B5025f

user1@axilla zsh% xcodebuild -downloadComponent MetalToolchain
Beginning asset download...
Downloaded asset to: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/875502ca270b11aea673a097fac9a44111df081f.asset/AssetData/Restore/022-20562-007.dmg
Done downloading: Metal Toolchain 17B5025f.

user1@axilla zsh% xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.2.5025.6.bNci4j/Metal.xctoolchain/usr/bin/metal

user1@axilla zsh% su user2
Password:

user2@axilla zsh% xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.2.5025.6.bNci4j/Metal.xctoolchain/usr/bin/metal

user2@axilla zsh% ls -l ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist
ls: /Users/user2/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist: No such file or directory

Tested on macOS 26.0 25A354 on mac-arm64.

[breun (Nils Breunese)]

I've installed Xcode 26.1b1 17B5025f on macOS 26.0 25A354 arm64:

❯ xcodebuild -version
Xcode 26.1
Build version 17B5025f

I installed the Metal toolchain (xcodebuild -downloadComponent MetalToolchain) and xcodebuild -find metal works:

❯ xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.2.5025.6.NUwMte/Metal.xctoolchain/usr/bin/metal

But installing openjdk21 from source still fails:

❯ sudo port install -s openjdk21
--->  Computing dependencies for openjdk21
--->  Fetching distfiles for openjdk21
--->  Verifying checksums for openjdk21
--->  Extracting openjdk21
--->  Applying patches to openjdk21
--->  Configuring openjdk21
Error: Failed to configure openjdk21: consult /opt/local/var/macports/build/openjdk21-42c1353a/work/jdk-21.0.8+9/config.log
Error: Failed to configure openjdk21: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk21/openjdk21/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port openjdk21 failed

Because metal can't be found by configure:

:info:configure checking for metal... [not found]
:info:configure checking if metal can be run using xcrun... no
:info:configure configure: error: XCode tool 'metal' neither found in path nor with xcrun
:info:configure configure exiting with result code 1

[markmentovai (Mark Mentovai)]

Replying to breun:

This is almost certainly the problem I documented in comment:36.

As a workaround, reboot (to clear the macports user’s xcrun_db cache) and then use sudo -P port install openjdk21. The -P tells sudo to leave the supplementary group list alone, so it won’t call setgroups to establish root’s group membership. This means that supplementary group list won’t ever include the daemon group, so it won’t matter that port never calls initgroups or setgroups. Without being a member of group daemon, the build should have access to the Metal toolchain cryptex mount point.

I must note that this is just a workaround. MacPorts needs to be made to handle the supplementary group list properly when it drops and restores privileges. But as a workaround, the sudo -P trick should unblock you.

[breun (Nils Breunese)]

I committed openjdk25 as a new port. Buildbot builds succeed for macOS 15, but failed on macOS 26 arm64 (x86_64 not attempted yet) due to metal not being found: ​https://build.macports.org/builders/ports-26_arm64-builder/builds/12392/steps/install-port/logs/stdio

Ryan, is the Metal toolchain installed on that buildbot?

[breun (Nils Breunese)]

I've ​asked for support on the macports-dev mailinglist last week, but no response so far. This ticket is assigned to me, but I don't what can be done to make these ports that require the Metal toolchain build successfully on macOS 26 Tahoe.

[ryandesign (Ryan Carsten Schmidt)]

Replying to breun:

I committed openjdk25 as a new port. Buildbot builds succeed for macOS 15, but failed on macOS 26 arm64 (x86_64 not attempted yet) due to metal not being found: ​https://build.macports.org/builders/ports-26_arm64-builder/builds/12392/steps/install-port/logs/stdio

Ryan, is the Metal toolchain installed on that buildbot?

Yes; see comment:9.

[breun (Nils Breunese)]

Replying to ryandesign:

Yes; see comment:9.

Ok, so it fails on the buildbots in the same way as we see it fail locally. Do you think that Mark's assessment that MacPorts needs to be made to handle the supplementary group list properly when it drops and restores privileges (comment:39) is the key to getting this fixed?

[markmentovai (Mark Mentovai)]

Replying to ryandesign:

Replying to breun:

Which user installs the Metal toolchain on the buildbots?

I was logged in as the buildbot user, which is the normal user account I created when installing macOS.

It is the same user that builds the port?

No, mpbb installs ports using sudo port install so they start as root and then drop privileges to the macports user.

Then the supplementary group list almost certainly contains daemon, which blocks access to the Metal toolchain via cryptexd’s mount (as used on arm64) for non-root, such as when MacPorts drops privileges without relinquishing daemon group membership.

As a workaround, try sudo --preserve-groups port install … in place of sudo port install …. That will make sudo not call setgroups to set the supplementary group list to include root’s group membership. As long as the supplementary group list doesn’t contain daemon to start, daemon won’t be introduced at this step. This is only a temporary workaround and a way of demonstrating that the problem is understood. I’m not suggesting that anyone use sudo --preserve-groups long-term.

Before trying that, do these steps:

1. Make sure that that daemon isn’t already in the supplementary group list at the time that sudo --preserve-groups port install … is run. It should be enough to show that the mpbb user can successfully ls /private/var/run/com.apple.security.cryptexd from the same context that it normally runs sudo port install …. I’ll expand more on this point in the “direct demonstration of the privilege problem” below, and you can also try those commands to get a better understanding of the problem on your system.
2. Clear xcrun’s cache by removing ${TMPDIR}/xcrun_db as the macports user. If the macports user had tried running xcrun metal while there was a problem (such as a permission problem), it may have cached a bad result for metal’s path.
3. As the macports user, run xcodebuild -showComponent MetalToolchain as the macports user. This ensures the presence of ~/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist. (​FB20389216, and it seems that this will no longer be necessary in Xcode 26.1.)
4. If you’re running on x86-64 and another user (not macports) has mounted the Metal toolchain, run diskutil eject $(xcodebuild -showComponent MetalToolchain | sed -E -n -e 's/^Toolchain Search Path: (.*)$/\1/p') to unmount the other user’s instance, as only one can have the toolchain mounted at a time (​FB20390263). (I know that the buildbot in question is arm64, but I’m including this here for completeness. On the other hand, if you’re on x86-64, you probably won’t see the daemon group membership problem, because cryptexd doesn’t mount the Metal toolchain in a daemon-inaccessible location on x86-64.)

For troubleshooting, if things don’t work, you can try these as the macports user:

• Run xcodebuild -find metal. This is lower-level than xcrun, and doesn’t consult the xcrun_db cache.
• Run xcrun_verbose=1 xcrun --find metal. The verbose output may be valuable. You can also make xcrun ignore its xcrun_db cache by setting xcrun_nocache=1.
• Look at the contents of ${TMPDIR}/xcrun_db.

Here’s a direct demonstration of the privilege problem, using sudo to achieve the privilege changes, noting that sudo calls setgroups, but sudo --preserve-groups does not.

# 0. Note the missing group access bits on this directory, denying access to
# group daemon.
user@axilla zsh% ls -ld /private/var/run/com.apple.security.cryptexd
drwx---r-x  8 root  daemon  256 Oct 18 14:04 /private/var/run/com.apple.security.cryptexd

# 1. An ordinary user, not a member of group daemon, can see inside this
# directory.
user1@axilla zsh% ls /private/var/run/com.apple.security.cryptexd
codex.system		inventory-ephemeral	mnt
init			inventory-persistent	shdw

# 2. Root, a member of group daemon, can see inside this directory too, because
# (a) root is the owner and has access, and (b) uid 0 is special, and has
# access regardless of filesystem permissions.
user1@axilla zsh% sudo ls /private/var/run/com.apple.security.cryptexd
codex.system		inventory-ephemeral	mnt
init			inventory-persistent	shdw

# 3. You can switch to root and then back to the ordinary user, and see inside
# this directory.
user1@axilla zsh% sudo sudo --user=user1 ls /private/var/run/com.apple.security.cryptexd
codex.system		inventory-ephemeral	mnt
init			inventory-persistent	shdw

# 4. If you don’t call setgroups or initgroups when switching back to the
# ordinary user, the supplementary group list will contain daemon, and access to
# this directory is blocked. This simulates the current MacPorts problem.
user1@axilla zsh% sudo sudo --user=user1 --preserve-groups ls /private/var/run/com.apple.security.cryptexd
ls: /private/var/run/com.apple.security.cryptexd: Permission denied

# 5. If you also don’t call setgroups when switching to root, then the
# supplementary group list will never have daemon added to it, so it doesn’t
# matter that nobody called setgroups or initgroups when switching back to the
# ordinary user. It’s possible to see inside this directory again. This
# simulates my proposed temporary workaround.
user1@axilla zsh% sudo --preserve-groups sudo --user=user1 --preserve-groups ls /private/var/run/com.apple.security.cryptexd
codex.system		inventory-ephemeral	mnt
init			inventory-persistent	shdw

If, after following these steps, sudo --preserve-groups allows the macports user to access the Metal toolchain, then it’s very strong evidence that the the supplementary group list being allowed to continue containing daemon when running as the macports user is at fault, per comment:36 and comment:39. The correct solution would be to make MacPorts handle the supplementary group list properly when changing privilege levels. That would fix these Metal toolchain problems, but it would also close the unexpected hole that MacPorts is running with more privilege than expected (such as having membership in group admin).

[breun (Nils Breunese)]

Replying to markmentovai:

Here’s a direct demonstration of the privilege problem, using sudo to achieve the privilege changes, noting that sudo calls setgroups, but sudo --preserve-groups does not.

(...)

If, after following these steps, sudo --preserve-groups allows the macports user to access the Metal toolchain, then it’s very strong evidence that the the supplementary group list being allowed to continue containing daemon when running as the macports user is at fault, per comment:36 and comment:39. The correct solution would be to make MacPorts handle the supplementary group list properly when changing privilege levels. That would fix these Metal toolchain problems, but it would also close the unexpected hole that MacPorts is running with more privilege than expected (such as having membership in group admin).

That's some great investigation work, Mark! I can reproduce all of your example commands that show the difference between running with and without --preserve-groups.

However, sudo --preserve-groups port install openjdk17 still fails on macOS 26 for me with configure: error: XCode tool 'metal' neither found in path nor with xcrun. It fails with same error for openjdk21 and openjdk25.

[markmentovai (Mark Mentovai)]

Replying to breun:

However, sudo --preserve-groups port install openjdk17 still fails on macOS 26 for me with configure: error: XCode tool 'metal' neither found in path nor with xcrun. It fails with same error for openjdk21 and openjdk25.

Can you try steps 2 and 3 from comment:45, running as your macports user? If you still have trouble, do the troubleshooting steps after, also as your macports user?

[markmentovai (Mark Mentovai)]

Replying to markmentovai:

I realize that this step may not be clear:

2. Clear xcrun’s cache by removing ${TMPDIR}/xcrun_db as the macports user. If the macports user had tried running xcrun metal while there was a problem (such as a permission problem), it may have cached a bad result for metal’s path.

You need to be sure you’re getting the MacPorts user’s temporary directory—we’re trying to get at what NSTemporaryDirectory would return to that user. sudo doesn’t initialize TMPDIR, so you’ll need to find another way to find the one belonging to the macports user. One reliable way to do this is:

admin@axilla zsh% sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"

Let me help put all of this together. I’ll demonstrate the cache problem using openjdk17 as an example. After running the above command, but not using sudo --preserve-groups, the build fails:

admin@axilla zsh% sudo port -s install openjdk17
--->  Computing dependencies for openjdk17
--->  Fetching distfiles for openjdk17
--->  Attempting to fetch jdk17u-jdk-17.0.17+10.tar.gz from https://distfiles.macports.org/openjdk17
--->  Verifying checksums for openjdk17                                         
--->  Extracting openjdk17
--->  Applying patches to openjdk17
--->  Configuring openjdk17
Error: Failed to configure openjdk17: consult /opt/local/var/macports/build/openjdk17-623b00ce/work/jdk17u-jdk-17.0.17+10/config.log
Error: Failed to configure openjdk17: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk17/openjdk17/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port openjdk17 failed

admin@axilla zsh% sudo sudo --user=macports --preserve-groups xcrun --find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
admin@axilla zsh% sudo sudo --user=macports --preserve-groups xcrun metal --version
error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

Now I’ll introduce sudo --preserve-groups. The build still fails, because xcrun cached the wrong path for metal when it wasn’t able to access it at the correct path:

admin@axilla zsh% sudo --preserve-groups port -s install openjdk17
--->  Computing dependencies for openjdk17
--->  Configuring openjdk17
Error: Failed to configure openjdk17: consult /opt/local/var/macports/build/openjdk17-623b00ce/work/jdk17u-jdk-17.0.17+10/config.log
Error: Failed to configure openjdk17: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk17/openjdk17/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there
is a bug.
Error: Processing of port openjdk17 failed

admin@axilla zsh% sudo --preserve-groups sudo --user=macports --preserve-groups xcrun --find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
admin@axilla zsh% sudo sudo --user=macports --preserve-groups xcrun metal --version
error: error: cannot execute tool 'metal' due to missing Metal Toolchain; use: xcodebuild -downloadComponent MetalToolchain

But if I remove the macports user’s xcrun_db and try again with sudo --preserve-groups, everything’s fine:

admin@axilla zsh% sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"
admin@axilla zsh% sudo --preserve-groups port -s install openjdk17
--->  Computing dependencies for openjdk17
--->  Configuring openjdk17
--->  Building openjdk17                                 
--->  Staging openjdk17 into destroot                    
Warning: openjdk17 installs files outside the common directory structure.
--->  Installing openjdk17 @17.0.17_0+release+server
--->  Activating openjdk17 @17.0.17_0+release+server
--->  Cleaning openjdk17
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.                             
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  openjdk17 has the following notes:
    If you want to make openjdk17 the default JDK, add this to shell profile:
    export JAVA_HOME=/Library/Java/JavaVirtualMachines/openjdk17/Contents/Home

And, this should be unsurprising now, but xcrun --find metal running as the macports user, simulating how permissions were gained and dropped as in the above successful run, finally gives a good path:

admin@axilla zsh% sudo --preserve-groups sudo --user=macports --preserve-groups xcrun --find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS/Metal.xctoolchain/usr/bin/metal
admin@axilla zsh% sudo --preserve-groups sudo --user=macports --preserve-groups xcrun metal --version
Apple metal version 32023.830 (metalfe-32023.830.2)
Target: air64-apple-darwin25.0.0
Thread model: posix
InstalledDir: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS/Metal.xctoolchain/usr/metal/current/bin

There are only two hard problems in computer science: cache invalidation, naming things, and off-by-one errors.

[breun (Nils Breunese)]

Thanks for the elaborate explanation, but the commands that let you build openjdk17 still fail for me on macOS 26.0.1 arm64:

sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"
~ ❯ sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"
~ ❯ sudo --preserve-groups port -s install openjdk17
--->  Computing dependencies for openjdk17
--->  Configuring openjdk17
Error: Failed to configure openjdk17: consult /opt/local/var/macports/build/openjdk17-623b00ce/work/jdk17u-jdk-17.0.17+10/config.log
Error: Failed to configure openjdk17: configure failure: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk17/openjdk17/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port openjdk17 failed

And the error is still the same:

~ ❯ grep metal /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_java_openjdk17/openjdk17/main.log | tail -n 1
:info:configure configure: error: XCode tool 'metal' neither found in path nor with xcrun

[markmentovai (Mark Mentovai)]

As a blunt hammer to reset the xcrun_db cache, you can also reboot and then try ,sudo --preserve-groups port -s install openjdk17 again.

Still having trouble? Let's dig deeper. Can you show the results of these troubleshooting steps from comment:45?

• sudo --user=macports xcodebuild -find metal
• sudo --user=macports env xcrun_verbose=1 xcrun --find metal
• sudo cp "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db" /tmp/macports.xcrun_db, and then examine (or share) /tmp/macports.xcrun_db

[breun (Nils Breunese)]

I rebooted and ran sudo --preserve-groups port -s install openjdk17, but it still failed with the same error.

Here are the results from those commands:

~ ❯ sudo --user=macports xcodebuild -find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
~ ❯ sudo --user=macports env xcrun_verbose=1 xcrun --find metal
xcrun: note: database key is: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk|/Applications/Xcode.app/Contents/Developer|<manpath>
xcrun: note: lookup resolved in '/var/folders/0g/h7jhc5315zqc1n_n4_ny9q400000gp/T/xcrun_db' : '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:'
xcrun: note: PATH = '/Users/breun/.gem/ruby/3.3.6/bin:/Users/breun/.rubies/ruby-3.3.6/lib/ruby/gems/3.3.0/bin:/Users/breun/.rubies/ruby-3.3.6/bin:/Users/breun/.jenv/shims:/opt/local/bin:/opt/local/sbin:/opt/local/bin:/opt/local/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS:/Applications/Ghostty.app/Contents/MacOS:/Users/breun/.gem/bin:/Users/breun/Applications/docker_remove_untagged:/Users/breun/Applications/docker_repull:/Users/breun/Applications/ngrok:/Users/breun/Applications/index_drives:/Users/breun/Applications/mp_checksum:/Users/breun/Applications/git-open'
xcrun: note: SDKROOT = '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk'
xcrun: note: TOOLCHAINS = ''
xcrun: note: DEVELOPER_DIR = '/Applications/Xcode.app/Contents/Developer'
xcrun: note: XCODE_DEVELOPER_USR_PATH = ''
xcrun: note: xcrun_db = '/var/folders/0g/h7jhc5315zqc1n_n4_ny9q400000gp/T/xcrun_db'
xcrun: note: xcrun via metal (xcrun)
xcrun: note: database key is: metal|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk||/Applications/Xcode.app/Contents/Developer|
xcrun: note: lookup resolved in '/var/folders/0g/h7jhc5315zqc1n_n4_ny9q400000gp/T/xcrun_db' : '/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal'
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal
~ ❯ sudo cp "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db" /tmp/macports.xcrun_db
~ ❯ sudo cat /tmp/macports.xcrun_db
mR1L�U
�%��
�
�               �
                 /

                    b                                                                                                                                                                    tE��# �       ���0�h�v�@��
7
 R��e��u��
/Applications/Xcode.app/Contents/Developer|/opt/local/var/macports/build/openjdk17-623b00ce/work/.home||<timestamp>1758075160macosx|/Applications/Xcode.app/Contents/Developer|<sdklookup>|Path/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk|/Applications/Xcode.app/Contents/Developer|<sdklookup>|PlatformPath/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk|/Applications/Xcode.app/Contents/Developer|<manpath>/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.sdk|/Applications/Xcode.app/Contents/Developer|<manpath>/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:xcodebuild|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.sdk||/Applications/Xcode.app/Contents/Developer|/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuildxcodebuild|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk||/Applications/Xcode.app/Contents/Developer|/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuildclang|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk||/Applications/Xcode.app/Contents/Developer|/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang|<toolchain-signature>1758659851|1758659851clang++|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk||/Applications/Xcode.app/Contents/Developer|/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++|<toolchain-signature>1758659851|1758659851metal|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX26.0.sdk||/Applications/Xcode.app/Contents/Developer|/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal|<toolchain-signature>1758659851|1758659851/Applications/Xcode.app/Contents/Developer|/Users/breun||<timestamp>1758075160/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk|/Applications/Xcode.app/Contents/Developer|<sdklookup>|PlatformPath/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk|/Applications/Xcode.app/Contents/Developer|<manpath>/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:metal|/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk||/Applications/Xcode.app/Contents/Developer|/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal1758659851|1758659851/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk|/Library/Developer/CommandLineTools|<manpath>/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk/usr/share/man:/Library/Developer/CommandLineTools/usr/share/man:/Library/Developer/CommandLineTools/Toolchains/XcodeDefault.xctoolchain/usr/share/man:make|/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk||/Library/Developer/CommandLineTools|/Library/Developer/CommandLineTools/usr/bin/makeg++|/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk||/Library/Developer/CommandLineTools|/Library/Developer/CommandLineTools/usr/bin/g++clang++|/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk||/Library/Developer/CommandLineTools|/Library/Developer/CommandLineTools/usr/bin/clang++clang|/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk||/Library/Developer/CommandLineTools|/Library/Developer/CommandLineTools/usr/bin/clangar|/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk||/Library/Developer/CommandLineTools|/Library/Developer/CommandLineTools/usr/bin/arranlib|/Library/Developer/CommandLineTools/SDKs/MacOSX26.sdk||/Library/Developer/CommandLineTools|/Library/Developer/CommandLineTools/usr/bin/ranlib|/Applications/Xcode.app/Contents/Developer|<manpath>/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man:/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/usr/share/man:/Applications/Xcode.app/Contents/Developer/usr/share/man:/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/share/man:xcodebuild|||/Applications/Xcode.app/Contents/Developer|/Applications/Xcode.app/Contents/Developer/usr/bin/xcodebuild%

Is there a better way to inspect /tmp/macports.xcrun_db than to cat it?

[markmentovai (Mark Mentovai)]

Replying to breun:

I rebooted and ran sudo --preserve-groups port -s install openjdk17, but it still failed with the same error.

Here are the results from those commands:

~ ❯ sudo --user=macports xcodebuild -find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

OK, stop right there. Now we’re getting somewhere! That path is wrong (it refers to the stub inside Xcode and not to the Metal toolchain), and if it’s wrong, nothing else downstream can ever possibly be right.

Let’s rewind to comment:22. Do you have a file at ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist? If so, what’s in it?

admin@axilla zsh% sudo plutil -convert xml1 -o - ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<array>
[…]
	<dict>
		<key>affinity</key>
		<string>available</string>
		<key>assetBuildUpdate</key>
		<string>17A324</string>
		<key>assetType</key>
		<string>metalToolchain</string>
		<key>xcodeBuildUpdate</key>
		<string>17A400</string>
	</dict>
[…]
</array>
</plist>

But I suspect you’re hitting ​FB20389216, which is still broken in Xcode 26.0.1 (should be fixed in 26.1 which is currently at beta 3, however). In that case, you might see:

admin@axilla zsh% sudo plutil -convert xml1 -o - ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist
/opt/local/var/macports/home/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist: (The file “XcodeToMetalToolchainIndexMapping.plist” couldn’t be opened because there is no such file.)

And indeed, if I remove that file, I get the same incorrect result from xcodebuild -find metal that you do:

admin@axilla zsh% sudo rm ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist
admin@axilla zsh% sudo --user=macports xcodebuild -find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

If the file’s not present, try to get it to spring into existence. Try:

admin@axilla zsh% sudo --user=macports xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS

If that worked, ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist should now exist—go back and try the plutil command from above to verify. And if it exists and has reasonable content xcodebuild -find metal should also return a good path:

admin@axilla zsh% sudo --user=macports xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS/Metal.xctoolchain/usr/bin/metal

From there, you can repeat the steps in comment:45 to get back on track.

admin@axilla zsh% sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"
admin@axilla zsh% sudo --user=macports xcrun --find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS/Metal.xctoolchain/usr/bin/metal
admin@axilla zsh% sudo --preserve-groups port -s install openjdk17
[…]

[breun (Nils Breunese)]

Replying to markmentovai:

Replying to breun:

I rebooted and ran sudo --preserve-groups port -s install openjdk17, but it still failed with the same error.

Here are the results from those commands:

~ ❯ sudo --user=macports xcodebuild -find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

OK, stop right there. Now we’re getting somewhere! That path is wrong (it refers to the stub inside Xcode and not to the Metal toolchain), and if it’s wrong, nothing else downstream can ever possibly be right.

Let’s rewind to comment:22. Do you have a file at ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist? If so, what’s in it?

No, I don't have this file.

But I suspect you’re hitting ​FB20389216, which is still broken in Xcode 26.0.1 (should be fixed in 26.1 which is currently at beta 3, however). In that case, you might see:

admin@axilla zsh% sudo plutil -convert xml1 -o - ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist
/opt/local/var/macports/home/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist: (The file “XcodeToMetalToolchainIndexMapping.plist” couldn’t be opened because there is no such file.)

And indeed, if I remove that file, I get the same incorrect result from xcodebuild -find metal that you do:

admin@axilla zsh% sudo rm ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist
admin@axilla zsh% sudo --user=macports xcodebuild -find metal
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/metal

If the file’s not present, try to get it to spring into existence. Try:

admin@axilla zsh% sudo --user=macports xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS

Ok.

~ ❯ sudo --user=macports xcodebuild -showComponent MetalToolchain
Asset Path: /System/Library/AssetsV2/com_apple_MobileAsset_MetalToolchain/4ab058bc1c53034b8c0a9baca6fba2d2b78bb965.asset/AssetData
Build Version: 17A324
Status: installed
Toolchain Identifier: com.apple.dt.toolchain.Metal.32023
Toolchain Search Path: /private/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.J9EjBw

If that worked, ~macports/Library/Developer/Xcode/XcodeToMetalToolchainIndexMapping.plist should now exist—go back and try the plutil command from above to verify.

That file indeed exists now.

And if it exists and has reasonable content xcodebuild -find metal should also return a good path:

admin@axilla zsh% sudo --user=macports xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS/Metal.xctoolchain/usr/bin/metal

Looks good too:

~ ❯ sudo --user=macports xcodebuild -find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.J9EjBw/Metal.xctoolchain/usr/bin/metal

From there, you can repeat the steps in comment:45 to get back on track.

admin@axilla zsh% sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"
admin@axilla zsh% sudo --user=macports xcrun --find metal
/var/run/com.apple.security.cryptexd/mnt/com.apple.MobileAsset.MetalToolchain-v17.1.324.0.t40qgS/Metal.xctoolchain/usr/bin/metal
admin@axilla zsh% sudo --preserve-groups port -s install openjdk17
[…]

This worked, also for openjdk21 and openjdk25!

[markmentovai (Mark Mentovai)]

Replying to breun:

Fantastic!

So, comprehensively, here is the command sequence to fix the Metal toolchain for MacPorts’ use, for mac-arm64:

This is the step that people are likely to have tried anyway, but it won’t hurt to run it again. As any user, if it hasn’t been done yet:

% xcodebuild -downloadComponent MetalToolchain
[…]

Then, make sure that xcodebuild running as the macports user can find the Metal toolchain, and clear the macports user’s xcrun cache in case it’s stored a bad path to the metal driver or other tools. Using sudo to run as the macports user or work with that user’s files:

% sudo --user=macports xcodebuild -showComponent MetalToolchain
[…]
% sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"

Then, as a temporary workaround until MacPorts handles the supplementary group list when changing privilege levels, use sudo --preserve-groups when building ports that use Metal. For example:

% sudo --preserve-groups port install openjdk25
[…]

Done!

Once it’s working, if the Metal toolchain later “goes bad” again at some point (perhaps because sudo port install was used without --preserve-groups), recover by clearing xcrun’s cache, by repeating:

% sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db"
% sudo --preserve-groups port install …
[…]

Ryan, the macOS 26 buildbot is still broken for these Metal-using ports (​openjdk17, ​openjdk21, ​openjdk25, ​qt6-qtwebengine). Are you able to perform these steps on the buildbot?

There should also be a follow-up ticket about MacPorts’ handling of the supplementary group list.

[breun (Nils Breunese)]

Replying to markmentovai:

There should also be a follow-up ticket about MacPorts’ handling of the supplementary group list.

Could you create this ticket?

[markmentovai (Mark Mentovai)]

Replying to breun:

Replying to markmentovai:

There should also be a follow-up ticket about MacPorts’ handling of the supplementary group list.

Could you create this ticket?

→ #73160 for making MacPorts set the supplementary group list when it changes privileges.

[jmroot (Joshua Root)]

Could you please test if the changes on the release-2.11 branch fix this?

[markmentovai (Mark Mentovai)]

Replying to jmroot:

Could you please test if the changes on the release-2.11 branch fix this?

I tested with ​release-2.11 at 1ef9d3947ebf. I’m able to use sudo port -s install openjdk17 successfully without the need for the sudo --preserve-groups workaround. On mac-arm64, macOS 26.0.1 25A362 with Xcode 26.0.1 17A400, this installed ​openjdk@17.0.17_0+release+server. Good! Thanks, Joshua.

Of course, this initgroups fix only makes it possible for MacPorts when running unprivileged to see the Metal toolchain within /private/var/run/com.apple.security.cryptexd. It doesn’t resolve the other underlying problems (not that it was supposed to). sudo --user=macports xcodebuild -showComponent MetalToolchain and sudo rm -f "$(sudo --user=macports getconf DARWIN_USER_TEMP_DIR)/xcrun_db" may still be necessary to get the Metal toolchain to work for the macports user—this is ​FB20389216, outside of MacPorts’ control, and it will hopefully be fixed in Xcode 26.1. There’s also ​FB20390263, affecting x86-64, where multiple users can’t access the Metal toolchain simultaneously—also outside of MacPorts’ control.

[breun (Nils Breunese)]

​MacPorts 2.11.6 has been released with the fix for the supplementary group list issue (#73160).

[markmentovai (Mark Mentovai)]

#73180 seeks a build of these ports on the buildbot now that #73160 is fixed and MacPorts 2.11.6 has been released.

[markmentovai (Mark Mentovai)]

Xcode 26.1 doesn’t change anything here, but ​the steps in the wiki still work in conjunction with MacPorts 2.11.6.

(Why did this work with Xcode 26.1b1 but not Xcode 26.1? xcrun_db tracks things by toolchain, so I assume that the beta toolchain using a different (and perhaps in particular, non-default) slot caused things to behave differently.)

I don’t think there’s anything else to do here. I’d close the bug myself, but I don’t seem to be able to.

[breun (Nils Breunese)]

Thanks for your effort, Mark! I’ll close this ticket now.