(:title The "root wheel" Issue: Fixing a Broken Mac OS X Print Provider:)
Some of our users have reported running into strange problems with fresh installs of a PaperCut Application Server or Secondary Server on their Mac OS X machines. As soon as the PaperCut Print Provider starts monitoring the printers on their servers, all print jobs start getting stuck in the operating system’s queues with a status of “Paused”. When they try running the “Control Print Monitoring.command” script to make adjustment, they encounter nasty error messages. They’ve double-checked that sandboxing has been set to relaxed for CUPS service running on the server to no avail, and as soon as PaperCut is uninstalled, everything returns to normal.
Sound at all familiar? If you’re having similar issues getting your Mac install to play nice, start by taking a look at the permissions on PaperCut’s own files. Open a Terminal window and switch to the following directory, replacing "[app-path]" with the install location of PaperCut:
Then, run the following command to list the files found here alongside their permissions:
The files should all be owned by the “papercut” user account; if that’s the case, each file’s listing here will look something like this:
-rwxr-xr-x 1 papercut admin 1.9M 31 May 16:09 pc-event-monitor
However, if you instead see something like this:
-rwxr-xr-x 1 root wheel 1.9M 31 May 16:09 pc-event-monitor
… then we know that something has gone awry during the install!
First things first, we should try running the “roottasks” and the “setperms” scripts found in this same location, in turn. These are normally run at the time of install, and then make sure that the PaperCut Print Provider has the requisite control and permissions in order to successfully interact with your print queues. These may have failed to run correctly right off the bat, so try each of them again now:
Once you have completed both of these runs, check the permissions once again. If the files still belong to the “root” user and “wheel” group, or if all printing otherwise remains unsuccessful, we’ll need to take more drastic measures.
Uninstall PaperCut from the server by using the “Uninstall.command” script found in the installation directory. Then, unbind the server from any domain it is currently joined to. This can be done by first opening the OS X “Directory Utility” application. Select, for example, the Active Directory connection from the available list.
Then, click the small edit button on the lower left, and then click to “Unbind…”.
Once done, reinstall PaperCut on the machine. Check the file permissions and test printing at this stage; if all seems to be well, rebind the server to the domain, and test once more.
Still having trouble? Next steps!
- Enable debug for the PaperCut Print Provider running on the Mac OS X server.
- Enable debug for the CUPS service running on the same server.
- Test a print job, confirming that it becomes stuck in the queue, and taking note of the time of print, the document name, the user who printed, and the name of the printer. Take a fullscreen screenshot of the job as shown in the print queue, as well as within the CUPS web interface if possible.
- Collect the “print-provider.log” and “error_log” files as per the instructions linked to in the steps above, and email them through to email@example.com along with the notes you took around your test print.
Categories: Implementation / Deployment, Apple macOS, Troubleshooting
Keywords: mac, osx, CUPS, root, wheel, zono,