Issue
After upgrading to Tahoe 26.2, print queues monitored by PaperCut no longer work. The print queue gets paused, and the jobs fail to print.
This issue was discovered during our internal testing prior to the Tahoe 26.2 public release, and a growing number of our mutual customers have also reported it since then.
Root cause
This appears to be due to changes in the behavior of CUPS Sandbox restrictions, which prevent the backend (and filter) from reading/writing to the PaperCut install folder.
Error messages
- From
syslog.
2025-12-22 16:41:59.283761+1100 0x1daf61 Error 0x0 0 0 kernel: (Sandbox) Sandbox: papercut(5783) deny(1) file-write-data /Library/Printers/PaperCut/Print Provider/print-provider.log
- When trying to create a TCP socket from the PaperCut filter.
2025-12-15 19:50:08,403 ERROR: os_tcp_socket_create: getaddrinfo failed: nodename nor servname provided, or not known
Technical details
PaperCut implements print queue monitoring using a CUPS backend (and filter).
CUPS backends and filters run in a security 'sandbox' which limits what they can do (such as file/folder access, create network sockets, and execute sub-processes, etc.).
The PaperCut backend (and filter) relies on some of these operations, so to function correctly, our code updates /etc/cups/cups-files.conf with "Sandboxing relaxed".
Until 26.2, this relaxed mode allowed us to read/write to PaperCut folders, create TCP sockets to communicate with the local PaperCut Application Server, and execute/kill sub-processes.
As an alternative to the relaxed mode, we also tried "Sandboxing off", but that doesn't help either (from CUPS scheduler/conf.h).
typedef enum
{
CUPSD_SANDBOXING_OFF, /* No sandboxing */
CUPSD_SANDBOXING_RELAXED, /* Relaxed sandboxing */
CUPSD_SANDBOXING_STRICT /* Strict sandboxing */
} cupsd_sandboxing_t;
Test code
We can provide a simplified version of our backend that demonstrates the issue if required
Questions
- Has the CUPS sandbox relaxing changed? According to the CUPS man pages (cups-files.conf(5)), "Sandboxing relaxed" should still work as before.
- If this is the new intended behavior, what are the other options/directives we can use to relax the limitations on CUPS backends and filters?
