The installer package includes files that are only readable by the root user

It’s hard to say what’s causing this, but I do have suggestion for how to debug it. If you choose Distribute App > Custom > App Store Connect > Export, you get a copy of the installer package that would have been submitted if you’d chosen the Upload option. You can then dig into the installer package to see what’s what.

There are a couple of really good third-party apps to dig into installer packages. Alternatively, you can pull them apart by hand as explained in Unpacking Apple Archives.

Once you know what file is causing the problem, you can then work backwards through your build system to see how it got that way.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

The only file that has "other" -> none rights is the embedded.provisionprofile file.

Whoah, that’s weird.

this file is only created in the final packaging process

Right.

Well, more correctly:

• This file might be present in your development builds.

• But the packaging process has to override it when you upload to the App Store.

• That’s because the profile authorises a specific set of certificates.

• And the Apple Distribution certificate you use for App Store uploads is different from the Apple Development certificate you use for day-to-day development.

You can learn more about this in TN3125 Inside Code Signing: Provisioning Profiles.

It’s very weird that the profile is owned by root:wheel. I’m struggling to think of any way that might happen.

Xcode downloads these files from the Developer website and then stores them in ~/Library/Developer/Xcode/UserData/Provisioning Profiles [1]. Please check the ownership and permissions of the files there.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Or ~/Library/MobileDevice/Provisioning Profiles if you’re using an old version of Xcode.

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.

As I mentioned above, I’m a big fan of using GUI apps to explore installer packages. However, I think this is a case where it makes sense to use the command-line tools rather than an app, because that gives you a more direct view of what’s going on.

I created a new test project, add a restricted entitlement to it, and then exported an App Store Connect installer package. This is what I see:

% xar -xf Test788895.pkg 
% lsbom com.example.apple-samplecode.Test788895.pkg/Bom 
.   0   0/0
./Test788895.app    40755   0/0
./Test788895.app/Contents   40755   0/0
./Test788895.app/Contents/Info.plist    100644  0/0 1582    981317462
./Test788895.app/Contents/MacOS 40755   0/0
./Test788895.app/Contents/MacOS/Test788895  100755  0/0 202608  1379559329
./Test788895.app/Contents/PkgInfo   100644  0/0 8   742937289
./Test788895.app/Contents/Resources 40755   0/0
./Test788895.app/Contents/Resources/MainMenu.nib    100644  0/0 14262   622228364
./Test788895.app/Contents/_CodeSignature    40755   0/0
./Test788895.app/Contents/_CodeSignature/CodeResources  100644  0/0 2593    3272760510
./Test788895.app/Contents/embedded.provisionprofile 100644  0/0 12597   1737788395

Note how everything is 0/0, that is, root:wheel. That makes sense in this case because… well… no other value woud be reasonable.

Also note how the permissions for embedded.provisionprofile are 100644, or rw-r--r--. Again, that’s what I’d expect.

If you repeat the above with your installer package, what do you see?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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 pasted the full log on PasteBin

Thanks.

And, yeah, that clearly shows the problem:

./In the Line of Fire.app/Contents/_CodeSignature/CodeResources	100640	0/0	…
./In the Line of Fire.app/Contents/embedded.provisionprofile	100640	0/0	…

This is weird. It’s not at all clear how Xcode could generate a package with the permissions set that way.

If you follow the Distribute App > Custom > App Store Connect > Export workflow, the resulting directory includes a Packaging.log file. This shows all the steps taken by Xcode to build the package.

One critical step looks like this:

2025-06-25 08:58:09 +0000  Running /usr/bin/ditto '-V' '/Users/quinn/Library/Developer/Xcode/Archives/2025-06-25/Test788895 25-06-2025, 09.57.xcarchive/Products/Applications/Test788895.app' '/var/folders/n_/p9vcphfj2l7c7fmh0ct2f70w0000gp/T/XcodeDistPipeline.~~~6bzJzq/Root/Applications/Test788895.app'

This shows how Xcode copies the app from your .xcarchive into its temporary work location. Check out the profile embedded in the source app. Does it have the permissions set correctly?

In my test, I see this:

% ls -lh '/Users/quinn/Library/Developer/Xcode/Archives/2025-06-25/Test788895 25-06-2025, 09.57.xcarchive/Products/Applications/Test788895.app/Contents/embedded.provisionprofile'
-rw-r--r--  1 quinn  staff    21K 25 Jun 09:57 /Users/quinn/Library/Developer/Xcode/Archives/2025-06-25/Test788895 25-06-2025, 09.57.xcarchive/Products/Applications/Test788895.app/Contents/embedded.provisionprofile

I found a way to workaround it.

Cool.

You have a choice here. You can just live with that workaround or you can continue to investigate the root cause of this. I’d vote for the latter, but I’ll understand if you want to stick with the former.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

I like going for the root cause! :)

A man after my own heart!

Hmm, why do you have then the embedded.provisionprofile in your build?

This bit I can explain. Mac apps only need a provisioning profile if they use restricted entitlements. See TN3125 Inside Code Signing: Provisioning Profiles for more about that.

In my case I added a restricted entitlement to my test app [1] because I wanted to be sure that Xcode would add a profile during the distribution process. However, the fact that I added that entitlement means that Xcode also adds a profile to the Development-signed Release build in the Xcode archive.

It would be nice if Xcode could make these sanity checks itself and auto-correct the rights as it knows what rights are expected.

Xcode does do a lot of checks like this, but obviously not this one. Once we figured out what’s going on, it might make sense for you to file an enhancement request for this.

But (!) I can see the _CodeSignature folder and inside there it is already root-only!

Yeah, that’s definitely the thread we need to pull on. More on that in a bit.

Maybe Xcode applies automatically the same rights to the embedded.provisionprofile as the CodeSignature has.

I can’t see any logical reason for why it might be doing that. However, it’s possible that the same issue that’s causing this behaviour for _CodeSignature is also causing it for the profile. We’ll know more about the latter once we understand the former.

Coming back to _CodeSignature, I have a quick diagnostic test for you to try out:

1. Create a new project from Xcode’s macOS > App template.

2. Give it the same bundle ID as your real project.

3. In Signing & Capabilities, in the Team popup, select the same team as in your real project.

4. Choose Product > Archive.

5. In the resulting archive, does _CodeSignature have the permissions set correctly?

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.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] Specifically, I used Signing & Capabilities to add the Custom Network Protocol capability, which causes Xcode to add a com.apple.developer.networking.custom-protocol entry in my .entitlements file. There’s nothing significant about Custom Network Protocol. It’s just my go-to capability when I need to test stuff like this.

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

Is this the expected rights setup?

Nope. Here’s what I see with an equivalent test:

% cd Test788895C\ 27-06-2025,\ 14.36.xcarchive/Products/Applications/Test788895C.app/Contents/_CodeSignature 
% ls -l
total 8
-rw-r--r--  1 quinn  staff  2200 27 Jun 14:36 CodeResources

This is Xcode 16.4 on macOS 15.5, but I would expect to see rw-r--r-- permissions for all versions of Xcode and all versions of macOS.

Hmmm, so it’s an environmental issue. Interesting. If you’d asked me to bet on this, I would’ve put my money on it being a project issue. But, hey, that’s why we check these things.

I have a couple of new diagnostic tests for you. The first is a simplification of my original test:

• In step 2, give the app a unique bundle ID.

• In step 3, disable automatic code signing and select Sign to Run Locally in the Signing Certificates popup.

I’m hoping this continues to reproduce the problem. If not, stop now and write back here.

Assuming it does, I have the new test that I actually want you to run:

1. Create a new user account in System Settings > Users & Groups, switch to that account

2. Log out of your main account.

3. Log in to this test account.

4. Repeat the previous test.

The goal of this test is to see whether the environmental issue is local to your main user account or tied to your Mac as a whole.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

Hmmm, clearly there’s some sort of environmental weirdness going on here.

What version of macOS is this? And what version of Xcode? I’m gonna try setting that up in a VM here in my office, to see if I can reproduce this in on a ‘fresh’ machine [1].

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] This was another reason for my Sign to Run Locally test. Setting up code signing in a VM can be a challenge |-:

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).