Using Job Trace to troubleshoot print job problems

Submission

Replication

Release

A user prints from their device, the job is analyzed, then the job is sent securely to the local Edge Node or Cloud Node (if enabled).

A successful submission is confirmed when the trace shows the Job status changed to pending-release, indicating the job is securely held in the user's queue.

After submission, the job is distributed from the first Edge Node to its peers on the local network.

When the Cloud Node is enabled, after the user releases the job, replication happens and the data is copied from the cloud down to the printing Edge Node.

During this time, the trace should log Assigning processor candidates to the job.

Success is marked with the line Job status changed to assigned.

Triggered by the user releasing the job at the printer, the local Edge Node sends the job to the physical printer using a defined print method (like IPPS or RAW/9100) with the message Job status changed to printing

The lineJob status changed to printed tells us the print job was sent to the printer without error.

documentcheck.inaccessible

This highlighted issue happens when an Edge Node in the mesh is selected to forward the print job to the printer but can't fetch the document from the user's computer (or Cloud Node if enabled). Most commonly this happens when the user who printed the job is outside the network.

Possible causes:

• The print job was not accessible from either the Cloud Node or from another Edge Node in the mesh. This might be the case if the user’s computer is not in the same network as the edge mesh and the Cloud Node is not enabled.

• Port 9264 is blocked between subnets or VLANs, preventing replication between Edge Nodes.

• The job file is too large to replicate. By default, the limit is 500 MB for print jobs replicated locally, and 200 MB for jobs replicated via the Cloud Node.

• This message is logged when one candidate edge node cannot retrieve the print documents, however for printing to be successful only one edge node needs to be able to print the job.

Recommendations:

• Enable the Cloud Node — It helps avoid network limitations by replicating jobs through the cloud, facilitating printing even if users are outside the network.

• Test port 9264 — which is required for connectivity between the user’s computer and an Edge Node with access to the printer. From an affected user’s device, use a command like:
  Test-NetConnection -Port 9264 -ComputerName <other-node-ip>

• Consider job sizes — If this happens specifically with large print jobs, contact PaperCut Support to discuss increasing the limit.

• Check other highlighted issues — If there are other highlighted issues, this may not be the primary problem.

jobrouter.assignprocessor.noEdgeNodeCanPrintTheJob

This highlighted issue, accompanied by the phrase 'there are no printable edgenodes' means the job router couldn’t find an Edge Node capable of printing the specific job to the chosen printer (e.g., no Edge Node online with access to the target printer or the right type of queue). Please note this error will show as 'Failed: no edge nodes available to communicate with printer' in the Activity tab of a print job.

Possible causes:

• The printer is offline.

• The user’s computer, or any Edge Node has not reported it has access to the printer.

• The printer’s IP address has changed but hasn’t been detected by a scheduled scan yet.

• Printer Protocol configuration is not compatible with “Print Methods” available for the printer (IPP not available for example for USB printers).

• Edge Nodes cannot reach the printer on the required ports.

Recommendations:

• Review setup — Ask "which nodes are supposed to have access to this printer?". Make sure at least one or more reliable edge nodes are able to reach the printer on the network. See Best Practices for print job delivery in PaperCut Hive and Pocket and consider setting up a printer delivery profile for the site, particularly in complex environments with strict network segmentation.

• Test network access — from the Edge Node to the printer. From the Edge Node open a browser and enter the IP address of the printer to try accessing the printer's web interface. Alternatively, use terminal or PowerShell commands from the Edge Node to test the connection to each port (SNMP/161, IPP/631 or 443, or RAW/9100). For example:

  • Windows: Test-NetConnection -Port 9100 -ComputerName <printer-ip>

  • macOS/Linux: .\pc-edgenode-service -command test-ipp-print <printer-ip>

• Check the logs — If there's one Edge Node which should have access to the printer, consider downloading and reviewing the Edge Node Logs to check for any issues, like low disk space.

• Verify the printer’s IP — Search for the printer's IP in Hive. If this has changed recently, re-scan it in the Pocket/Hive admin console.

• Check the delivery type — For example, if the printer does not support IPP, make sure other delivery types are available.

jobrouter.assignprocessor.jobNotPickedUp

This highlighted issue means PaperCut Hive or Pocket tried to assign the print job to one or more Edge Nodes, but none accepted the job with the message “job not picked up by any processors”. This error will display in the Activity tab of a print job as 'Failed: edge nodes selected for job delivery were unresponsive or unable to perform the job'. This suggests problems with Edge Node availability, network issues preventing the Edge Node from receiving instructions, or Edge Nodes being overloaded, or edge nodes can’t currently see the printer.

Possible causes:

• This might happen if the nodes in the Edge Mesh reject the job for another highlighted issue, like documentcheck.inaccessible or cmdexecutiontimeout.

• The Edge Node may have previously seen the printer, but currently cannot (for example, changed network recently).

• The Edge Node can see the printer via SNMP, but the printing port such as Port 9100 is blocked. See required ports on the PaperCut Hive System Requirements page here.

• Connection issues. High network latency or low bandwidth between your site and the PaperCut Cloud prevented the Edge Node from accepting the print task in a timely fashion.

• Performance problems. Edge Nodes are online but under heavy load (e.g. high CPU), and don’t respond to the job request.

• Ports blocked. Edge Nodes can’t connect to the MQTT network (used to coordinate job delivery).

Recommendations:

• Review other errors — There may be another highlighted issue which causes this error. For example, documentcheck.inaccessible could mean the Edge Nodes were unable to fetch the document from the user's computer who submitted the job. Whereas cmdexecutiontimeout could mean that the printer hardware is not responding to the Edge Nodes.

• Verify the ports — Check that Edge Nodes chosen to print are able to connect to the printer via the required delivery port (Port 9100 or IPP(s) 80/443/631) on the current network.

• Check that Edge Nodes can reach the MQTT network — used for coordinating job delivery (as specified in Pocket and Hive system requirements):

  • mqtt.notifications.cloud.papercut.com

  • mqtt2.notifications.cloud.papercut.com

  • mqtt3.notifications.cloud.papercut.com

• Ensure reliable communication to the MQTT network — Some customers have let us know that disabling SSL packet inspection resolved this issue.

• Make sure candidate Edge Nodes (or Super Nodes) are not resource-constrained — (e.g. high CPU or limited memory). Make a note of the Printing Edge Node Candidates at the top of the job trace. The devices listed here are the candidates PaperCut Hive or Pocket tried to notify to deliver the job to the target printer. If restarting the edge node doesn't fix the issue, sharing the edge node logs with PaperCut support for review.

• Set up a printer delivery profile — to help guide the job through specific reliable printing clients on your network. See: Configuring Print Delivery profiles. We recommend this over our old advice of setting up a Super Node.

jobrouter.releasequeue.previousJobAborted

This highlighted issue means a job failed to release because an earlier job in the same batch was aborted. It’s a follow-on error that appears during a batch release (for example, when a user clicks Release All). If the first job in the sequence fails, the later jobs inherit this error and return to the “Pending Release” state.

To fix it, you’ll need to track down and resolve the error on the first job that failed.

Possible causes:

• Since this is a follow-on error, the cause is always that a preceding job in the batch failed. The underlying cause is whatever error stopped that first job.

Recommendations:

• Check other highlighted issues first — If there are other highlighted issues for the batch of jobs in the Job Trace, they might point to the root cause of the failure.
  

• Find the first failing job in the Job Log — Go to the Job Log in the admin consol and look for the cluster of jobs that failed at the same time. Identify the first one, then check its specific error and trace to uncover the problem.
  

• Release jobs individually as a workaround — If the issue only happens with batch-releasing jobs, users may be able to release their jobs one at a time while you troubleshoot. This skips the batch process and might avoid the cascading error.

edgenode.processor.print.actionFailure

This highlighted issue indicates that the Edge Node failed to send the print job to the physical printer. It often comes with a sub-error that tell us why it failed (such as edgenode.processor.print.actionFailure.ippCreateJobFailed).

Possible causes:

The root cause of this error message, is dependent on which Print Delivery Protocol is being used to send the job to the printer.

• Local queue delivery - This happen because of a problem with the print queue on the Edge Node.

• IPP (Internet Printing Protocol) - PaperCut Hive or Pocket is unable to communicate with the printer using IPP, for example the printer is busy and is not accepting IPP jobs.

• Raw Printing: 9100 - because of network, firewall, or other reasons the printer may not be reachable on port 9100.

Recommendations:

• Look for a sub-error with more detail: .socketConnectionTimeout (unable to establish connection), .socketWriteFailed (the connection was abruptly closed), .ippCreateJobFailed (IPP protocol issues), .jobStopped (job canceled at the printer), .jobTimeout (printing took too long).

• Configure print queues in Pocket/Hive — when you set up a print queue in Pocket or Hive which uses a manufacturer’s driver, that can sidestep many printing pitfalls. Once you do this, PaperCut will default to using the OEM driver as the primary print delivery method. See: Creating and deploying PaperCut print queues and drivers.

• Set up a printer delivery profile — to help guide the job through specific reliable printing clients on your network. See: Configuring Print Delivery profiles. We recommend this over our old advice of setting up a Super Node.

edgenode.processor.print.actionFailure.failedToMonitor

This highlighted issue means the Edge Node sent the job to the printer, but the printer stopped responding before the edge node could track the final status.

Possible causes:

• The printer’s firmware or IPP service crashed while processing a complex job (for example, a large PDF).

• The printer’s internal spooler is stuck and not accepting new jobs.

• A network interruption (like a reboot, port failure, or power loss) made the printer unreachable mid-print.

• Ongoing network issues, such as packet loss or a firewall closing the connection, disrupted communication.

Recommendations:

• Check the output — Confirm with the user if the job physically printed, either fully or partially.

• Restart the printer — Power cycle it to clear memory and reset the network stack.

• Test IPP printing — Not all printers handle IPP well, especially during batch printing. If the job used IPP, try updating the printer firmware. You can also test the printer using the method in the article Some jobs failed to print. Try again" error message

• Change the delivery method — In practice we’ve found IPP/IPPS is the least reliable option. Using the manufacturer’s driver usually sidesteps these issues, and you can set this up in a couple of ways. In the Hive or Pocket admin console, click Printers, click the 3 dots next to the printer in question, and select Details. On the Advanced tab, specify a custom Print Protocol and pick one of these options:

  • Local queue delivery — Log onto a dedicated Super Node, on Windows open Print Management Console, and set up a print queue with the print driver of your choice pointing to the printer.

  • Raw printing (port 9100) - in the Hive or Pocket interface, choose Create a Print queue and follow the prompts to set up a custom print queue with a manufacturer’s driver. This can be a direct or Find-Me (secure release) queue. See: Creating and deploying PaperCut print queues and drivers.

edgenode.processor.print.actionFailure.jobStopped

This highlighted issue indicates the print job was halted on the printer, possibly due to a printer error, a user intervention, or a specific printer state.

Possible causes:

• This error might be expected if a print job was cancelled by a user at the device.

• A problem with the printer such as a paper jam, causing an error in the print queue.

Recommendations:

• Ask the user — check with the user to ask whether they intentionally canceled the job at the printer.

• Check the printer — to see if there was some condition that prevented the device from printing the job such as a paper jam. Restart the printer if needed.

• Test the local queue — If printing via a local queue on an Edge Node, log onto the printing Edge Node and open Print Management Console on Windows. Ensure a Windows test page can be sent to the printer successfully.

edgenode.processor.print.actionFailure.socketWriteFailed

This highlighted issue means the client started a connection with the printer, but had a problem trying to write (send) data.

Expand the highlighted issue to see more detail. For example:

jobprocessor [3]

1:01:40 AM 9/30/2025

err=error:write tcp 10.51.85.66:63004->10.51.85.50:9100: i/o timeout writing to printer: {10.51.85.50 9100}. Written 69632 bytes, duration:10m0.0076058s, {10.51.85.50 9100}, duration:10m0.017434

The above detail tells us specifically that the edge node (10.51.85.66) timed out when attempting to write to the printer at 10.51.85.50 using port 9100. This could be a printer or network issue.

Possible causes:

• The printer abruptly closed the connection while data was being written.

• A network appliance, like a firewall or proxy terminated the session mid-transfer.

Recommendations:

• Network trace — Use command line tools like traceroute to examine the hops between the Edge Node and printer to understand the network path.

• Investigate each hop — Ask if any of the hops between the Edge Node and the printer might be filtering or blocking network traffic.

• Test printing — Make a note of the Print Delivery Protocol used to deliver the print job (IPP, local queue, or RAW/9100). Try testing out printing outside of Pocket and Hive. For testing methods see: Some jobs failed to print. Try again".

• Change the delivery method — PaperCut Pocket and Hive support different ways of delivering jobs to printers. Sometimes an issue with one can be sidestepped by switching to another protocol. In the Hive or Pocket admin console, click Printers, click the 3 dots next to the printer in question, and select Details. On the Advanced tab, specify a custom Print Protocol and pick one of these options:

  • Local queue delivery — Log onto a dedicated Super Node, on Windows open Print Management Console, and set up a print queue with the print driver of your choice pointing to the printer.

  • Raw printing (port 9100) - in the Hive or Pocket interface, choose Create a Print queue and follow the prompts to set up a custom print queue with a manufacturer’s driver. This can be a direct or Find-Me (secure release) queue. See: Creating and deploying PaperCut print queues and drivers.

edgenode.processor.print.actionFailure.ippCreateJobFailed

This highlighted issue means that something went wrong with sending the job to the printer using the IPP protocol.

Possible causes:

• We’ve found that specific printers advertise IPP support but may have issues with multiple concurrent print jobs (batch printing). When this happens certain printer models stop accepting jobs.

• Although IPP has been around as a protocol since 1999, it has not been as widely implemented as RAW/9100 nor as thoroughly tested.

Recommendations:

• Narrow down the problem —Determine if this only affects specific printer models

• Upgrade the firmware — Work with your copier dealer to upgrade the firmware on these devices to the latest recommended version from the manufacturer.

• Test IPP printing — Not all printers handle IPP well, especially during batch printing. If the job used IPP, try updating the printer firmware. You can also test the printer using the method in the article Some jobs failed to print. Try again" error message

• Change the delivery method — In practice we’ve found IPP/IPPS is the least reliable option. Using the manufacturer’s driver usually sidesteps these issues, and you can set this up in a couple of ways. In the Hive or Pocket admin console, click Printers, click the 3 dots next to the printer in question, and select Details. On the Advanced tab, specify a custom Print Protocol and pick one of these options:

  • Local queue delivery — Log onto a dedicated Super Node, on Windows open Print Management Console, and set up a print queue with the print driver of your choice pointing to the printer.

  • Raw printing (port 9100) - in the Hive or Pocket interface, choose Create a Print queue and follow the prompts to set up a custom print queue with a manufacturer’s driver. This can be a direct or Find-Me (secure release) queue. See: Creating and deploying PaperCut print queues and drivers.

edgenode.processor.print.actionFailure.jobTimeout

This highlighted issue means that the job started sending to the printer but either took too long to print or there was no confirmation of successful delivery. Troubleshooting will depend on whether the job was delivered via a print queue or directly to the printer.

Possible causes:

• The print queue on the edge node is in an error state. Possibly because the printer is in an error state, or some more specific issue involving the Windows print spooler or CUPS.

Recommendations:

• Test the local queue — If printing via a local queue on an Edge Node, log onto the printing Edge Node and open Print Management Console on Windows. Ensure a Windows test page can be sent to the printer successfully.

• Restart the spooler — If the print queue on the Edge Node is in error, try clearing the print job by restarting the print spooler (Windows) or CUPS (macOS and Linux).

• Check the printer — Make sure the printer hardware is not in an error state, like low toner.

.

printercheck.unreachable

This highlighted issue means the Edge Node cannot establish basic communication with the printer. This is a general "unreachable" error that could stem from network problems (firewall, routing), the printer being powered off, or the printer not responding to the Edge Node's checks.

Possible causes:

• This error may be logged even when the job prints successfully. Sometimes the printer is simply unreachable because SNMP on port 161/162 is blocked or the SNMP community string on the printer is not public, but the job will still print.

• The edge node or super node cannot reach the printer on the network (e.g., due to network segmentation, firewall rules, or the printer being offline). This could be because users and devices are on separate subnets, preventing proper communication. Or network ports are blocked, preventing the edge node from accessing the printer.

• The printer is not available or is in an error state.

Recommendations:

• Check SNMP - when SNMP is blocked, print jobs may still go through, but PaperCut Hive and Pocket may not be able to fetch the toner levels of the printer or the Page Meter Count of the printer on the Analytics tab may not be current. For tips on troubleshooting SNMP connectivity, see: Why can’t I find my printer in the PaperCut Hive or Pocket admin console?

• Check connectivity — Ensure that the printing edge node or super node can reliably reach the printer on the network.

• Is the printer online — Confirm that the printer is online and not in an error state.

• Test the ports — Check that necessary ports (such as 9100 for manufacturer drivers or 443 for IPPS) are open and accessible.

printercheck.unreachable.9100ping

This message means the edge node couldn’t talk to the printer over TCP port 9100. It only appears if the print queue is set up with a manufacturer driver, which means PaperCut will try to use Raw printing: 9100 as the Primary delivery method.

In some setups, this error may even be expected — for example, if the end user’s computer can’t directly reach the printer over the network.

Possible causes:

• The edge node is on a different network, subnet, or VLAN than the printer.

• A firewall or antivirus on the edge node is blocking outbound connections on port 9100.

• A network firewall between the edge node and the printer is stopping the traffic.

• The printer is offline or its IP address has changed.

Recommendations:

• Verify Port 9100 connectivity — From the edge node computer mentioned in the highlighted issue, check that the printer responds on its raw printing port 9100. For example:

  • macOS/Linux: nc -vz <printerIP> 9100

  • Windows: Test-NetConnection -ComputerName <printerIP> -Port 9100

• Enable the Cloud Node — If the user is on a different network from the printer, this is often the simplest fix. A Cloud Node securely routes jobs through the internet, letting any edge node deliver them to the right printer.

• Review security software — Local firewall or antivirus software can sometimes get in the way. Allow outbound traffic on TCP 9100 or create an exception for PaperCut Pocket/Hive.

Printercheck.unreachable.cmdexecutiontimeout

PaperCut Hive or Pocket tried to query the printer using IPP/IPPS, but the request timed out. The system waited ~30 seconds for a reply over ports 631 or 443 from the printer and never received one. Because the pre-check failed, the job couldn’t be released.

Possible causes:

• The printer does not have IPP/IPPS enabled.

• The printer is not reachable on its IPP/IPPS port (443 or 631) possibly due to firewall or network configuration.

• The printer supports IPP but is overloaded or slow to respond.

• No other delivery method is configured or working when the job is being processed so PaperCut Pocket/Hive has defaulted to using IPP as a last effort.

Recommendations:

• Check that IPP/IPPS is enabled on the printer — Some models ship with it disabled or require explicit setup. Confirm with your manufacturer or reseller.

• Verify IPP connectivity — From the edge node, check that the printer responds on its IPP/IPPS port (443 or 631). For example:

  • macOS/Linux: nc -vz <printerIP> 443

  • Windows: Test-NetConnection -ComputerName <printerIP> -Port 443

• Test IPP printing — Not all printers handle IPP well, especially during batch printing. If the job used IPP, try updating the printer firmware. You can also test the printer using the method in the article Some jobs failed to print. Try again" error message

• Change the delivery method — In practice we’ve found IPP/IPPS is the least reliable option. Using the manufacturer’s driver usually sidesteps these issues, and you can set this up in a couple of ways. In the Hive or Pocket admin console, click Printers, click the 3 dots next to the printer in question, and select Details. On the Advanced tab, specify a custom Print Protocol and pick one of these options:

  • Local queue delivery — Log onto a dedicated Super Node, on Windows open Print Management Console, and set up a print queue with the print driver of your choice pointing to the printer.

  • Raw printing (port 9100) - in the Hive or Pocket interface, choose Create a Print queue and follow the prompts to set up a custom print queue with a manufacturer’s driver. This can be a direct or Find-Me (secure release) queue. See: Creating and deploying PaperCut print queues and drivers.