1

I have an application that generates a significant amount of non-persistent data during runtime, only for my use case, but not other users.

The software itself lacks a built-in mechanism to automatically delete this data, because other users do not have this need.

Therefore, I aim to create a RamDisk to manage this data. This approach would serve two purposes: minimizing wear and tear on my hard drive while simultaneously freeing up space automatically.

To achieve this, I removed the application's default data directory and replaced it with a symbolic link pointing to a directory on the RamDisk.

The application's data paths are located at (for example purposes only; not actual application names or paths):

~/Library/Containers/com.app.name/Data/Library/Application Support/AAA
~/Library/Containers/com.app.name/Data/Library/Application Support/BBB
~/Library/Containers/com.app.name/Data/Library/Application Support/CCC

I used the following command is a shell script:

echo “⚙️  Creating ${RAM_MB}MB RamDisk...”
DEVICE_ID=$(hdiutil attach -nomount “ram://$((RAM_MB * 2048))”)

echo “⚙️  RamDisk device id: $DEVICE_ID”
DISK_ID=$(echo $DEVICE_ID | awk ‘/^\/dev/{print $1; exit}’)

diskutil apfs create “$DISK_ID” RamDisk >/dev/null
echo “✅ RamDisk created at: $RAM_PATH”

To create the RamDisk

And by

ln -s /Volumes/RamDisk/AAA "~/Library/Containers/com.app.name/Data/Library/Application Support/AAA" 
ln -s /Volumes/RamDisk/BBB "~/Library/Containers/com.app.name/Data/Library/Application Support/BBB" 

to link the application's original data paths to the RamDisk.

The owner of this symbolic link is MyUsername:staff, and the directory within the RamDisk is the same.

However, I've noticed that the application seems unable to write content to the symbolic links.

I also tried changing the permissions of the root directory on the RamDisk to 777, but it didn't make any difference.

Here's my guess:

The application's data path contains "Containers" , so I suspect this is macOS's application sandboxing mechanism preventing the app from writing data outside the sandbox.

However, RamDisk itself isn't required by the application, so I can't use conventional methods to allow the app to write data to RamDisk.

Does anyone know how to resolve this issue? Or are there any other approaches that don't require a RamDisk?

I am using macOS 15.6.

Much appreciated.

4
  • It used to be that removing an Application's code signature would also remove the sandbox. But I'm not sure about modern macOS. In particular, on Apple Silicon binaries must have a code signature to run at all. Maybe re-signing with an ad-hoc signature would work? (Obviously, Gatekeeper must be disabled for any of this.) Commented Nov 9 at 11:37
  • @Wowfunhappy Your solution worked perfectly. After re-signing the application using sudo codesign --force --deep --sign - /Applications/AppName.app, the application's data path indeed moved from ~/Library/Containers/com.app.name to ~/Library/Application Support/AppName. Additionally, the trick I described earlier using symbolic links and RamDisk now functions correctly. Commented Nov 9 at 12:04
  • The app I mentioned also offers a non-Mac App Store version on its official website. However, I initially chose the App Store version precisely to keep its permissions better controlled within acceptable limits. But realistically speaking, you can't have both security and convenience. Commented Nov 9 at 12:05
  • Great, I turned it into an answer. I probably should have done that in the first place but I wasn't entirely positive it would still work on modern systems. Commented Nov 9 at 22:24

1 Answer 1

0

App sandboxing is tied to app entitlements, which is tied to the application's code signature. So, replace the existing code signature with your own:

sudo codesign --force --deep --sign - /Applications/AppName.app

This should remove the sandbox. Note that this will break some applications, but there is only one way to find out!

You will need to have the developer tools installed in order to use codesign. You also may need to allow the app through Gatekeeper.

3
  • In my case, I didn't need to completely disable Gatekeeper; I only had to set it to App Store and identified developers. I recall that ten years ago, when Apple first introduced System Integrity Protection on Mac, disabling it was indeed necessary to set Gatekeeper to Anywhere. In fact, quite a few applications required this Anywhere setting. Commented Nov 11 at 2:02
  • I hadn't used a Mac for nearly five years until purchasing one again this year. I discovered that some applications which previously required Gatekeeper to be set to Anywhere to function properly (through unofficial modifications, like some Finder enhancement apps or plugin) no longer need this setting. Commented Nov 11 at 2:02
  • Again, I'm referring to the specific Apps I'm using. If anyone finds the steps in this Q&A not working, please try disabling SIP and setting Gatekeeper to Anywhere, then try again. Commented Nov 11 at 2:07

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.