Recently updated to Big Sur. Previously in Catalina (and prior) I was able to open a print dialog box, select the PDF drop down and choose a preset folder I had saved (Dropbox/Receipts folder) where macOS would then generate a PDF of whatever I was trying to print and drop it into that folder.

~/Library/PDF Services still has this folder alias but when I select it to "print" to, there is no PDF file generated.

I've read some stuff about PDF Services changing in Big Sur but no conclusive answer how to bring back this essential function where I can print anything to PDF to a preset folder with like 3 clicks.

  • 1
    Booting a clean install of macOS Big Sur 11.4, and making a folder named PDF Services in ~/Library, then adding a Finder alias named Save to PDF Documents, which points to a folder named PDF Documents in my Documents folder, to the PDF Services folder, now Save to PDF Documents shows on the PDF popup menu in the Print dialog box. So, it still work in macOS Big Sur and I'd suggest you recreate the Finder alias to the target folder you want the documents saved to. Jul 2, 2021 at 19:34
  • @user3439894 did you confirm that it generates the PDF and saves it in the folder? Jul 2, 2021 at 19:48
  • RE: "did you confirm that it generates the PDF and saves it in the folder?" -- Well of course I did. Why else would I had gone thru the process to make the first comment that I did? (Rhetorical question!) Jul 2, 2021 at 19:53
  • ok just checking. So further testing - it works on a folder created OUTSIDE of Dropbox but not on a folder created inside Dropbox. I gave Dropbox full disk permissions but may have to try to reinstall the client as a next step. Jul 2, 2021 at 19:58
  • 1
    Sorry I do not use Dropbox or I would have tested with it, however, it was important to let you know that the process still works in general. Jul 2, 2021 at 20:13

2 Answers 2


My diagnosis:

When I print with Save to any folder not in my home folder nothing appears in the destination. So this is not a Dropbox issue.

The Console log includes this:

error   09:04:57.913422+1000    kernel  Sandbox: printtool(7104) deny(1) file-write-create /Volumes/T5/Sync/Dropbox/folder/file.pdf
error   09:04:57.914103+1000    printtool   #print Failed to run workflow (-108)

So this is a sandbox issue with the printtool process.

Workaround 1:

This workaround (which fails so far) is an attempt to enable printtool to avoid the sandbox. For this we can add the printtool executable to Full Disk Access in Security & Privacy. The path to add is: /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/PrintCore.framework/Versions/A/printtool. printtool

But this is does not work (even after a reboot)!! Perhaps another step is needed.

Workaround 2:

My other workarounds avoid using the print processing to write the PDF. This is rather clumsy but works. In the print dialog choose Save as PDF and save to the Dropbox folder.

Workaround 3:

Automate the processing, using a local folder for printing and some automatic processing to move the PDF where we want in Dropbox.

  1. In PDF Services add an alias to a folder which is under the home directory. I used ~/Documents/DropboxPrint with an alias renamed to Save to Dropbox. Printing to that will work.

  2. Either: For the folder chosen create a Folder Action and script to move the PDF to Dropbox, or (slightly easier) create rule in Hazel to move the file to a folder (e.g. called Print) inside Dropbox.

Hazel Rule

This works because we have avoided the restrictions on printtool and used Hazel which already has Full Disk Access.


UPDATE: This problem is fixed in Monterey, which restores writing permissions to PDF Services. The solution is thus to update beyond Big Sur.

The problem is that as of Big Sur, PDF Services has been massively sandboxed so as to render it useless.

error   09:33:50.180022+0100    kernel  Sandbox: printtool(5086) deny(1) file-write-create /Users/Shared/Print/Out/big sur - Fix-restore "Print to PDF" to preset location in Big Sur - Ask Different.pdf

The only thing I have found that works is an Automator Application (nb: not 'workflow' or anything else). Presumably, applications have local code-signing or something that lets them through the sandbox. So you will need to create an Automator sequence that saves the file to your destination.

The problem also affects executables, like shell and python scripts. Automator Print plug-ins no longer work either.

Relax the sandbox

However, this sandboxing can be 'fixed' by adding the words Sandboxing Relaxed to /etc/cups/cups-files.conf. You can do this from within the CUPS web front-end (Administation tab > Edit Configuration File button), or just with Terminal or with BBEdit etc. You'll need to restart cupsd if you don't use the web front-end.

This seems to allow printtool a bit more freedom, but the executables it calls are still subjected to various restrictions.

Please 'send feedback' to Apple.

  • I would happily give half my points and my daughter's hand to anyone who can provide a better fix.
    – benwiggy
    Jul 4, 2021 at 10:00
  • See my answer. Workaround 3 is pretty easy, particularly if you use Hazel. But it is a workaround, not a fix. Unsandboxing would be a fix.
    – Gilby
    Jul 4, 2021 at 23:08
  • Yes, I'm looking for a fix! I have lots of python scripts that manipulate PDFs in various ways: create booklet, make PDF/X-3. I can wrap them in an Automator app, or could put them in a workflow for a Folder Action, but it's just another nail in the coffin of usability.
    – benwiggy
    Jul 5, 2021 at 6:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .