Thanks for the feedback, will do.

Thank you, it worked with using the ProcessBuilder Class. Code ... ProcessBuilder processBuilder = new ProcessBuilder(); processBuilder.command("osascript", "<path>/<applescript name>.app"); try { Process process = processBuilder.start(); ...

Your comments / My replies [My Comment]: For starters, really really appreciate your insight, expertise and assistance. Want to say thank you up front! [Your Comment]: "Oi vey! It looks like your app is modifying files inside of its own bundle. This is not supported [1] and will inevitably cause problems in the long term. You need to fix this." [My Reply]: Yes our application is self contained (executables, derby database, log files, etc) with the .app bundle, which we can distribute the entire application with only dealing with a single .app bundled file. This architecture has worked prior to macOSX Catalina with no issues for nearly 10 years. The backup function stopped working in Catalina and continues with Big Sur. Are you saying with the newer macOSXs, it does not support this type of "legacy" architecture (i.e. a single bundled application with executables, database, log files, etc)? If so, can you point me to an Apple architectural best practice documentation so I have some guidance on bundling an application using a derby database and logging system? [Your Comment]: "Hmmm, that’s strong evidence of a bug in your code. Given the context, it’s very likely that a file system operation has failed due to some MAC restriction." [My Reply]: Again, this code worked prior to macOSX Catalina, but I infer with the newer macOSX security model (e.g. MAC restriction), it has now turned what worked before into a bug which is a null pointer exception. Is there a coding technique best practice I should use to become compliant with this new MAC restriction? btw, I'll reference your supplied link - just want to know what I am looking for. [Your Comment About run.sh]: "That is going to cause problems. I encourage you to replace this with a native executable." [My Reply]: So run.sh is another "legacy" architecture technique and should be replaced with a native executable? If so, can you point me to an Apple architectural best practice documentation so I have some guidance. [Your Comment]: "Right. I suspect what’s happening here is as follows:"... [My Reply]: Your five steps to a failure crash definitely sounds plausible. So for an overall remedy: (1) unbundle the application executable code with the database and log files; (2) become compliant with the new macOSX MAC restrictions using On File System Permissions; and (3) replace run.sh with a native executable. Does that three part remedy sound right? I'll definitely have to nail down a road map from the current state to a future state application architecture before diving into this work effort!

Retried -v and Tried -vvv I am getting a different response now when I do -v and I did do -vvv. Here is what I am getting and it is after I opened the application and tried the backup function which failed. Looks like application data files were added / modified. robhoth@Robs-MacBook-Pro-2 MY MEDKAZ % codesign -v "MedKaz.app" MedKaz.app: a sealed resource is missing or invalid robhoth@Robs-MacBook-Pro-2 MY MEDKAZ % codesign -vvv "MedKaz.app" MedKaz.app: a sealed resource is missing or invalid file added: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/dbex.lck file added: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/db.lck file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/seg0/c3161.dat file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/seg0/c90.dat file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/seg0/c3150.dat file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/log/log98.dat file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/log/logmirror.ctrl file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/database/toBackup/medkazDB/log/log.ctrl file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/medkaz.gui.properties file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/derby.log file modified: /Volumes/MY MEDKAZ/MedKaz.app/Contents/Resources/Java/error.log robhoth@Robs-MacBook-Pro-2 MY MEDKAZ % codesign -s "Developer ID Application: HEALTH RECORD CORPORATION (QFX3AN8WBH)" "MedKaz.app" MedKaz.app: is already signed robhoth@Robs-MacBook-Pro-2 MY MEDKAZ %  Answers to your questions Q: What’s the source? A: MedKaz.app on the USB drive. Q: And what’s the destination? A: MacBook SSD folder Q: What error do they fail with? A: Previous stack trace error. 2021-04-29 23:09:41,071 ERROR com.hrc.utilities.Helper (Helper.java:1272) Could not copy from ../../../.. to /Users/matt/Desktop/Jones Merle M 04.29.2021 java.lang.NullPointerException      at com.hrc.utilities.Helper.copyDirectory(Helper.java:1252)      at com.hrc.common.BackupFacade.backup(BackupFacade.java:69)      at com.hrc.ui.util.DialogDisplayHub$5.doInBackground(DialogDisplayHub.java:922)      at com.hrc.ui.util.DialogDisplayHub$5.doInBackground(DialogDisplayHub.java:910)      at org.jdesktop.swingworker.SwingWorker$1.call(Unknown Source)      at java.util.concurrent.FutureTask.run(FutureTask.java:266)      at org.jdesktop.swingworker.SwingWorker.run(Unknown Source)      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)      at java.lang.Thread.run(Thread.java:748) Q: Is this copy being done by code run inside your app’s process? A: Backup process is run inside the application with a Helper copy file class method. Q: Is your main executable an actual executable? A: It points to run.sh. The application opens though and runs fine. It's just this backup / recover function that quit working. Actually started with Catalina and continues with Big Sur macOSXs. Here is run.sh: #!/bin/sh APP_DIR="${0%/*}/../.." SCRIPT_DIR="$( cd "$( dirname "${BASH_SOURCE[0]}" )" > /dev/null && pwd )" WORKING_DIR="$APP_DIR/Contents/Resources/Java" JAVA_HOME="$APP_DIR/Contents/Resources/jre/mac8" JAVA_EXEC="$SCRIPT_DIR/../Resources/jre/mac8/bin/java" cd "$WORKING_DIR" WORKING_DIR=`pwd` exec "$JAVA_EXEC" -Djsse.enableSNIExtension=false -Xdock:name="My MedKaz" -Xdock:icon="$WORKING_DIR/../medkaz.icns" -splash:"$WORKING_DIR/../splash.gif" -Xmx1024M -jar "$WORKING_DIR/medkaz.jar" exit 0 Q: Have you tested this on a ‘clean’ machine? A: Tested on the same MacBook (Big Sur 11.4) as I signed the application. I just tried on my old MacBook (Mojave 10.14.6) and the backup function works fine using the same USB drive containing our application that failed on Big Sur.

To answer your questions: I deleted the three Apple certificates I modified the trust levels on, and re-added them to KeyChain Access with keeping the trust defaults. Understood on using the code block, will use that going forward. I was already at home. No network issues that I know of. Retried Attempt I retried the code signing with keeping the trust defaults and evidently it worked this time - no error messages!! Not sure what codesign -v suppose to return, but no message when issuing that command. robhoth@Robs-MacBook-Pro-2 MY MEDKAZ % pwd /Volumes/MY MEDKAZ robhoth@Robs-MacBook-Pro-2 MY MEDKAZ % codesign -s "Developer ID Application: HEALTH RECORD CORPORATION (QFX3AN8WBH)" "MedKaz.app" robhoth@Robs-MacBook-Pro-2 MY MEDKAZ % codesign -v "MedKaz.app"                                                                    robhoth@Robs-MacBook-Pro-2 MY MEDKAZ %  Next Issue The original purpose for going down the route of code signing was to get inline with Big Sur's new security model. Prior to Big Sur, our application could make a backup with no issues using our backup/recover function. With Big Sur that function stopped working. I just retied the function (with the application signed), and it still does not work. What else is there that is preventing this function from working on Big Sur? The backup algorithm is simple, it makes a copy of the application files and saves them to the user's workstation drive location of their choice, nothing more, nothing less than that.

Platform is macOS (Big Sur), independent deployment, and the application is built using Eclipse. I installed both the Apple WorldWide Developer Relations Intermediate and the Deverloper ID Application Certificates. I set both certificates to trust for all users. When I go to code sign, it works for about 30 sec or so then comes back with the same warning message and errSecInternalComponent (see screen capture). I tried to sign it again and it came back as already signed, then went to verify and it says a code object is not signed at all. I am inferring that "most" of my application was signed and there's a code object that was not signed for whatever reason. Is there a log I can check to see what code object it is having a problem with?

Ok, I joined the Apple Developer Program, created an Apple Distribution certificate for Ad Hoc distribution. The certificate was installed in Keychain Access. When I run the command: % codesign -s "Apple Distribution: HEALTH RECORD CORPORATION (QFX3AN8WBH)" "MedKaz.app" I still get the following same error as I did with the Sectigo certificate: Please advise on next steps I can try to resolve this error.

So my understanding here is going through sectigo.com for an EV code signing certificate is not supported on the apple platform, and it is recommended to obtain an apple-issued code signing certificate. Question, can I use an apple-issued code signing certificate for both our .exe version of the application along with the .app one? Both versions are built in Eclipse using Ant. Curious if I'll have to keep the Sectigo code signing certificate for Windows purposes OR if I can use the apple-issued one for both macOSx and Windows purposes.

Yes, EV as in Extended Validation Certificate.

I appreciate your help! Here is the stack trace on Big Sur: 2021-04-29 23:09:41,071 ERROR com.hrc.utilities.Helper (Helper.java:1272) Could not copy from ../../../.. to /Users/matt/Desktop/Jones Merle M 04.29.2021 java.lang.NullPointerException      at com.hrc.utilities.Helper.copyDirectory(Helper.java:1252)      at com.hrc.common.BackupFacade.backup(BackupFacade.java:69)      at com.hrc.ui.util.DialogDisplayHub$5.doInBackground(DialogDisplayHub.java:922)      at com.hrc.ui.util.DialogDisplayHub$5.doInBackground(DialogDisplayHub.java:910)      at org.jdesktop.swingworker.SwingWorker$1.call(Unknown Source)      at java.util.concurrent.FutureTask.run(FutureTask.java:266)      at org.jdesktop.swingworker.SwingWorker.run(Unknown Source)      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)      at java.lang.Thread.run(Thread.java:748) Again, as a sanity check, I ran the same backup code (i.e. straight file copy from source to destination) on Mojave with no issues. The source is from a USB drive (where the portable application runs) and the destination is to the local workstation drive folder the user chooses. Only difference here is the environment of Mojave and Big Sur.

I am not sure what you mean by "is your app sandboxed". Is it in a sandbox test environment? ... to that the answer is no. No error is displayed. The code that initiates the file copy (that worked before on macOS Mojave) of what we're using for backup purposes is: public static void copyFile(File src, File dest) throws Exception { InputStream in = new FileInputStream(src); OutputStream out = new FileOutputStream(dest); // Transfer bytes from in to out 1000k buffer byte[] buf = new byte[1024 * 1000]; int len; while ((len = in.read(buf)) 0) out.write(buf, 0, len); out.flush(); in.close(); out.close(); } Code is pretty basic java code that writes bytes from a source to a destination.