Thanks for that. I see the documentation now on Sequoia in the man pages. It doesn't seem like I can specify the timeout for a package postinstall script, only if I specify a script for a specific bundle. Would you agree? Does a dictionary in a component plist need to refer to an app bundle? I don't really have a bundle to install for the package choice. To answer your question, there are very large libraries of audio content available for our program, and the install scripts help them with various options for installing/using this content - it can definitely take longer than 10 minutes.

Thanks for your replies. I'm not asking for advice on how to solve the problem in my app at this point. The app uses a library of content that has hundreds of thousands of mixed case files that go back many many years, and is used by both Windows and Mac versions. I'm looking for a yes or no answer. Ignore the network issue that Quinn mentioned - but thank you for highlighting that issue, I was not aware of it - you are always very thorough. But assume that this is the user's own Mac and it is not connected to a network that could have this problem. This is the scenario. A customer contacts me and says he bought a new Mac, and it is formatted with a case sensitive filesystem (presumably APFS case sensitive) so he can't use my program. He claims that Apple is moving towards case sensitivity and this will be the new normal so he wants his money back. Is it possible that this customer's Mac WAS shipped like this from Apple, or would there have had to been some user intervention to reformat the system. I feel like this is a yes or no question.

Ok, thanks for the reply. So as far as the installers go, localization is pretty much restricted to a few readme / license text files, and the system decides the rest based on the user's currently selected language in system preferences. It also seems like it might be tricky to determine the user's language in a postinstall script since the installer runs as root.

Hi Gary, I've encountered a similar problem, which I made a separate thread about here: https://developer.apple.com/forums/thread/702907 Were you ever able to solve your problem?

Ok, I will take your suggestion and open a DTS. At this point it seems like the question is at least in part easy to define: Should a privileged Helper be able to access a removable volume? Is the answer yes, or no? Does it work for other people? Try making a privileged helper according to EBAS and see if it can, say, access a file on a removable volume (or, the Downloads or Documents folder). Now with further testing here, the app CAN access removable volumes the first time it's run when the helper is installed, AND in my current testing it is also working the SECOND time (??). If I then close the app and run it again, a THIRD time, then it no longer works. There is no way at all to make it work after this, with the exception of manually unloading and uninstalling the daemon and helper. I don't understand this. How can I develop an app that will stop working for the user with no way to fix it?

Further to my last reply, I tried to work-around this by simply copying the installer package from the removable disk prior to running it. And... I've now discovered an 'even worse' problem, which is that the installation does not work ("install failed. Authorization is required to install the packages.") if the install -target is a removable disk. The symptoms are the same, it works only the very first time the privileged helper is installed and does not work again after that. For anyone else reading this, note that the title of this thread is misleading, because I mistakenly thought it could be fixed by manually checking the box in Full Disk Access. Is there any way to give the PrivilegedHelper access to removable volumes? If not, is there any different strategy I can use to run an installer package from my app? (aside from just opening the package in the GUI installer.app) For context, this is a download and installation manager, that is used to install many different packages, some quite large (plugins, additional content, etc..) for our main program.

Thanks for the VM suggestion - I will research that. In the mean time I tested it on a "fresh" clone of a Catalina drive I happen to have. I’m confused by what you mean by “app” in this context. What I meant by this specifically is the helper tool, which the app calls via XPC. I guess my thinking was that the helper tool would automatically be inheriting the TCC privilege. I did as you suggested and added code to the app itself to access the file on the removable disk. Indeed, the first time I run the app, a dialog asks me for permission to access removable disks (which it didn't before, and I can see the app has been successfully added to the Security 'Files and Folders' area) and it copies/renames the file successfully. However the helper tool still fails to run the file using installer. On the fresh Catalina disk, I get the exact same behavior. The helper tool can access and install the package successfully unless it's on a removable drive (or in Downloads folder etc.). So this issue does not seem to be specific to the development machine. Because if that’s not working you have bigger problems Gulp...

Thanks for the response. I made another discovery. The app CAN actually access the Downloads folder. But ONLY the first time it's run when the helper is installed. Then, it doesn't work again unless I launchctl unload and load. Also, I realize there is a bigger problem. Let me expand a bit on this, the download location is user selectable, since the installer packages may be quite large and users like to download them to an external volume. This is an important feature for our app, and unfortunately external volumes suffer from the same problem as the Downloads folder. (1) Is this expected behavior? (2) Is there any way around this? Thanks.

Have you or anybody else ever found a solution to this problem?

The feedback report number is FB8788850

In the error 73 case, was the package built and signed on 10.13? Or 10.14? There was no difference which OS was used to build/sign. We did upgrade the machine to OS 10.14 and stapling works now. Xcode 10 is still installed. Apple should perhaps update the requirements on this page: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution "Stapling an app requires macOS 10.12 or later."

With regards the stapling issue, how are you building myInstaller.pkg? With an Apple tool? Which one? pkgbuild was used to compile the pkg, and then it was signed by productsign. So to summarize where I stand: All steps including notarization are successful on both OS 10.13 and 10.14. Stapler fails on OS 10.13 with the error 73 message I reported in a previous message. I don't see any relevancy. You are talking about doing development on operating systems that are 2 and 3 major versions behind. Don't do that. Well my question WAS specifically about an older OS. At this point, I'm still not sure if stapler is compatible with 10.13. It seems like people expect it to work, but have not tried it. We can likely upgrade the machine to 10.14, I will find out and report back with my findings.

To add something that may be relevant after further testing... On another dev computer that our team has (with Mojave), stapler does work. When I type the following command for myInstaller.pkg (which HAS been successfully notarized) , I get a slightly different result on each machine. spctl -a -t install -vvvv myInstaller.pkg On the 10.13 machine: myInstaller.pkg: accepted source=Developer ID origin=Developer ID Installer: myCompany On the 10.14 machine: myInstaller.pkg: accepted source=Notarized Developer ID origin=Developer ID Installer: myCompany

Thank you. I have updated to OS 10.13.6 now. XCode 10 now works, and I can successfully notarize an installer package. However, I now have a problem stapling. (I have tried recompling and notarizing several times with same result) When I enter this command after notarizing: xcrun stapler staple -v "myInstaller.pkg" I get this: ... ... ... Downloaded ticket has been stored at file:///var/folders/pd/rf2jcjzj0g1f3hw04l19r1fcsq1r5/T/b65b63be-30e8-4ff6-986f-02682df537bc.ticket. Attempting to attach a new ticket to myInstaller.pkg. Let’s see how that works out. Processing: myInstaller.pkg Properties are {   NSURLIsDirectoryKey = 0;   NSURLIsPackageKey = 0;   NSURLIsSymbolicLinkKey = 0;   NSURLLocalizedTypeDescriptionKey = “Installer package”;   NSURLTypeIdentifierKey = “com.apple.installer-package-archive”;   “NSURLIsApplicationKey” = 0; } We do not know how to deal with trailer version 65055. Exepected 1 Although we wrote the ticket, the written data did not validate. Please restore myInstaller.pkg from backup to try again. The staple and validate action failed! Error 73.

Ok... On this page: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution "Notarization requires Xcode 10 or later. Building a new app for notarization requires macOS 10.13.6 or later. Stapling an app requires macOS 10.12 or later." This would seem to be saying that notarization is possible on 10.12, or maybe it can literally only be stapled on 10.12 but not notarized (not sure if that makes sense). Anyhow, I have an installer package that has been signed (on OS 10.12.6) and I would like to notarize it now (on OS 10.12.6). I am wondering if this is possible, if so presumably there is a command line tool set or Xcode version that I can download from my developer account. Hence my question.