Thanks for the hints. I used a tool called "suspicious package" to inspect the created PKG file and I went through all files. The only file that has "other" -> none rights is the "embedded.provisionprofile" file. As far as I understand the process (and with help of ChatGPT), this file is only created in the final packaging process, as I don't see the "embedded.provisionprofile" in the xcarchive file. So how to change that? If the xcode achives tool is auto handling the sigingin and packaging, why does it then create a file with wrong permissions? Or am I understanding something wrong? Thanks for your help. Martin

Thanks a lot Quinn. I've checked the build files, no provisionprofile file in there. Also nothing in between, plain vanilla Unity 2023 project exported to Mac Xcode. The root:wheel thing might be a display thing because of the tooling ("susipicious package"), but I am not sure. I manually unpacked the package file using the cpio tool. There all files were belonging to me (martin:staff). I checked also the profiles in "/Users/martin/Library/Developer/Xcode/UserData/Provisioning Profiles". All of those were root + group readable. I changed all those to 755 but that didn't change anything when rebuilding and re-creating the package. And I need to correct me, 2 files are root-only, the file "CodeResources" in the "_CodeSignature" subfolder is also root-only. I am absolutely not sure how to fix it. My first gut-feeling was, it is something the package & signing process of XCode needs to fix, to ensure all files are not only root-only. Any more idea how to solve it? Thank you very much for your help so far. Here's the screenshot before and after applying the 755 rights to the profiles.

Thanks a lot. Here is my output: % xar -xf "In the Line of Fire.pkg" % lsbom de.tlbm.inthelineoffire.mac.pkg/Bom I could not paste the whole text. It said "sensible lanugage" - and only 7k chars. I pasted the full log on PasteBin: https://pastebin.com/ynvpGuCq

I found a way to workaround it. I first created the .app and instead of using the Xcode mechanism to create and upload the package, I manually signed the app and created a package and used transporter then the upload it. Funnily, if not changing anything, I get the same "root-only" problem, but this time I did a chmod 755 for the app before signing it and that worked.

I like going for the root cause! :) Here is the PasteBin of the Packaging.log file: https://pastebin.com/r28y6pcc 2025-06-25 10:40:24 +0000 Running /usr/bin/ditto '-V' '/Users/martin/Library/Developer/Xcode/Archives/2025-06-25/In the Line of Fire 25.06.25, 12.39.xcarchive/Products/Applications/In the Line of Fire.app' '/var/folders/rq/k4wtl7js79s3ydcvfnpc42f80000gp/T/XcodeDistPipeline.~~~lJxpXe/Root/Applications/In the Line of Fire.app In that source app (first argument to the ditto command, there is (yet) no embedded.provisionprofile, that is only the in the generated .pkg file as it seems. Hmm, why do you have then the embedded.provisionprofile in your build? But (!) I can see the _CodeSignature folder and inside there it is already root-only! But what is weird then, why does Xcode use root-only then too for the embedded.provisionprofile. If it copies that from the source downloaded profile and I changed those to 755, it should work. It would be nice if Xcode could make these sanity checks itself and auto-correct the rights as it knows what rights are expected. That is at least my current understanding of it. Maybe Xcode applies automatically the same rights to the embedded.provisionprofile as the CodeSignature has. If so, it would need a preprocessing step to fix the rights in there, but at what stage in Xcode? drwxr-xr-x 3 martin staff 96 25 Jun 12:39 _CodeSignature drwxr-xr-x 6 martin staff 192 25 Jun 12:39 Frameworks -rw-r--r-- 1 martin staff 1938 25 Jun 12:39 Info.plist drwxr-xr-x 3 martin staff 96 25 Jun 12:39 MacOS drwxr-xr-x 3 martin staff 96 25 Jun 12:39 MonoBleedingEdge -rw-r--r-- 1 martin staff 8 25 Jun 12:39 PkgInfo drwxr-xr-x 4 martin staff 128 25 Jun 12:39 PlugIns drwxr-xr-x 7 martin staff 224 25 Jun 12:39 Resources martin@MartinS90NL943C Contents % cd _CodeSignature martin@MartinS90NL943C _CodeSignature % ls -l total 112 -rw-r----- 1 martin staff 54870 25 Jun 12:39 CodeResources

If this test project works as expected then it’s likely that the issue is something to do with how your main project is set up. OTOH, if this test project has the same issue then there’s some sort of environmental issue in play. I created the test project and the result is different, I see here 640 as rights. Is this the expected rights setup? % ls -l [...]TestCodeSignature 26.06.25, 21.03.xcarchive/Products/Applications/TestCodeSignature.app/Contents/_CodeSignature -rw-r----- 1 martin staff 2200 26 Jun 21:03 CodeResources % stat -f '%A %N' CodeResources 640 CodeResources

Sorry for the late answer, this ... Life™ thing came in between... I have a couple of new diagnostic tests for you. The first is a simplification of my original test: In step 2... Did that, result is: -rw-r----- 1 martin staff 2200 16 Jul 21:52 CodeResources Assuming it does, I have the new test that I actually want you to run. Create a new user account in System Settings > Users & Groups, switch to that account Log out of your main account... Did that too, result is this time different! The CodeResources FOLDER has 755, but the Coderesources FILE inside that folder has this, like the above test. So the folder's rights now are fine, file still wrong. :) -rw-r----- 1 martin staff 2200 16 Jul 21:52 CodeResources Best Martin

Here's the Mac and Xcode versions. German Mac OS. Maybe has to do with it ... it is a Kandji controlled Mac (MDM - https://www.kandji.io).

Ok, yeah, at least good that it is a local problem on my machine then. I will get in the next 2 weeks my shiny new M4 Macbook Pro and will check if I run in the same problem there.