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?