Issues with Web Print can manifest a few different ways.
- Users may see an error when submitting print jobs
- The admin may notice that the Web Print server is displaying an error in the Mobile & BYOD section in PaperCut.
- Certain types of files such as PDFs or images may fail to print if there’s a problem.
The good news is that we’ve seen most of the issues customers can encounter, and we’ve made an effort to document them here.
User sees errors after submitting print job
PaperCut’s Web Print allows users to send their documents to a printer with just a browser, simply by logging in and choosing the file they want to print. However, occasionally it doesn’t work as expected and the user might see an error message after submitting their print job. Let this article show you what each of these status messages mean and how you can get things working again.
Error | Cause & Resolution |
---|---|
| This means that the job has been successfully uploaded to Web Print and sent to the printer. If you’re not seeing the job after this, check to see if this issue happens without Web Print when simply printing from the server. For additional troubleshooting ideas, check out Missing Or Disappearing Print Jobs. |
| This means that the job has been successfully uploaded to Web Print, submitted to the printer, and is now held by PaperCut because Hold/Release or Find-Me Printing has been configured. In order to release the job, the user must release the print job after logging into a copier or a PaperCut Release Station. |
| PaperCut may be configured to deny print jobs for a lot of different reasons. One common example is that the user has run out of balance and their account is set to restricted, which would result in the message “Denied: Not enough available credit”. Print jobs may also be denied for being too large, for having too many pages, for having a disallowed file extension, or being in color or duplex. Usually this happens because the printer in PaperCut was configured this way on purpose. These settings are managed for each printer in PaperCut under Printers > [printer name] > Filters & Restrictions. |
| Seen to happen when a print script is enabled and requires a pop-up. Web Print works with Print Scripting but does not support pop-up notifications. You will either need to disable Print Scripting for this printer, or rewrite the script to ignore documents when the source is Web Print. |
| This means that Web Print is unable to print the job because the printer cannot be found, which can happen for several different reasons.
In most of those scenarios Web Print is unable to submit the print job, because the name of the “printer” in PaperCut does not actually match the name of a print queue that exists on the server or Sandbox. To resolve, log onto the PaperCut server running the Web Print Service or workstation running the Web Print Sandbox application and make sure that the print queue still exists and that the name matches what is in PaperCut. If the print queue or print server was renamed recently, then follow these steps in How to Rename a Printer to make sure the printer has also been renamed in PaperCut. Then try sending a test page to that printer, making a note of any Windows error that may appear, then troubleshoot accordingly. |
| This message will be preceded by It has been seen to happen in a couple situations:
If you’re running Web Print Default mode, log onto the PaperCut Application Server and make sure that the “PaperCut Print Provider” service is started following these steps. Also if you are encountering this message with an older version of PaperCut, try upgrading. If this is a Web Print Sandbox, log on as the workstation as the Web Print user account and ensure that you can print an Office document normally and there are no prompts or dialog boxes blocking the application from printing. Also try printing a Windows test page to the print queue (without Web Print) to ensure the print queue and printer are working as expected. |
| The Web Print Service or Sandbox is supposed to copy the print job to the %TEMP% directory but fails for these reasons that we’ve seen:
The exact steps to get this working will depend on whether this is the Web Print Service or Web Print Sandbox. If this is the Web Print service running as SYSTEM, then this directory will be located in Check the server where Web Print is running to ensure there is adequate disk space. Also if Web Print is running as a service account or if this is the Web Print Sandbox then check the permissions on the |
| This has been seen to happen for the same reason as the Unable copy print data file when preparing print job error, but when an image file is uploaded to Web Print instead of a PDF. We believe this happens when the “image handler” used by Web Print for images (like .png and .jpeg files) fails to print the job for some reason. We know from testing that you can encounter this error if the Service or Sandbox is unable to write to the Windows %TEMP% directory as described above.
Reach out to us through the link at the bottom of this article and let us know if you encounter this message for another reason. |
| This happens when the Web Print Service, which runs as local system by default, tries to submit a print job to a queue hosted on another print server but lacks permission. In the world of Windows the local system account has full admin rights on the local server, but cannot interact with anything on the network, including a print queue on another server, hence the error. Resolving this error depends on whether your PaperCut implementation is supposed to be using the Web Print Service (default) or Web Print Sandbox.
Curiously, you may also see that Office documents will succeed but PDFs and image files won’t. This is because office documents are printed through the Web Print Sandbox which runs as a domain user account, and PDFs fail because are printed by the Web Print Service which might be running as local system. Additionally this also has been seen to happen when someone edits the line An admin might have made this change deliberately because they wanted to hide the name of the print server in Web Print for security reasons or to make things simpler for users. A better method for hiding the name of the print server in Web Print is described on our page about using Javascript to customize the User Web interface. |
PDFs specifically are failing to print
The most common reason for PDFs failing to print is that Adobe Reader has never been opened by the user account running the Sandbox application, leading to an unacknowledged prompt in Adobe before it can be used. To resolve this, log on to the Web Print Sandbox using the relevant user account, then ensure that Adobe Acrobat Reader runs and opens a PDF document.
If you’ve already checked these steps and the issue persists, you can try using the built-in xpdf renderer (available in version 13.2 or above). To do this:
- Determine if you are running the Web Print service (Default mode) on the main PaperCut server or a Web Print Sandbox.
- On the server that is running Web Print navigate to the web-print.conf file located at
[app-path]/providers/web-print/[platform]/web-print.conf
. On a 64-bit Windows server running PaperCut MF this path might beC:\Program Files\PaperCut MF\providers\web-print\win\web-print.conf
. - Use a text editor such as Notepad running as administrator to open the file.
- Add the following as a new line:
options.pdf=xpdf
anywhere in the web-print.conf file. - Save the file. Do not modify any other lines.
- Restart the Web Print service on the PaperCut server or the Web Print Sandbox application.
- Test.
Image files specifically are failing to print
Web Print and Email to Print are both able to support the printing of picture / image files (e.g. BMP, DIB, GIF, JFIF, JIF, JPE, JPEG, JPG, PNG, TIF, TIFF). If you’re able to successfully print PDFs through either Web Print or Email to Print - but you’re not able to send images - it may be because you’re using default mode on an OS that doesn’t support picture files.
Check the ‘Web Print setup options (by platform)’ table on the Web print manual page (which applies to both Web Print and Email to Print). You may need set up a Web Print Sandbox server on Windows to support other file types.
Web Print server status is showing an error
On the PaperCut NG or MF server, under Enable Printing > Web Print there is a window which displays the status of the Web Print Service (Default Mode) and any Web Print Sandboxes.
Error | Cause & Resolution |
---|---|
Ready, waiting for new jobs. |
This is the standard message when Web Print is working as expected. Even so, users might have problems printing and if they do they will see a status message when submitting a print job that may give a clue to the problem. |
Web Print was manually stopped. |
This error is expected if the Web Print service was intentionally stopped or disabled. This may be the case if the feature is no longer in use, or if a Web Print Sandbox was set up to be used instead. However if you think this should be running, follow these steps to troubleshoot: Web Print Service (Default Mode): on the server running PaperCut open services.msc and check that the PaperCut server is started. Web Print Sandbox: Log into the computer running the Web Print application as the Web Print user, and make sure the application is running. |
Error: “The Web Print server is offline”
This error might be seen in the Application Log. You may also see it as an email alert if the Web Print server is offline and you’ve configured system notifications.
The full message is:
An application error was reported. Further action may be required: The Web Print server WEBPRINTSRV01 is offline. Make sure the pc-web-print application is running and can access “C:\Program Files\PaperCut NG\server\data\web-print-hot-folder”
This message might be expected if you’re no longer using Web Print, or if you’ve disabled the Web Print Service in favor of using a Web Print Sandbox. If this server has been decommissioned, follow our steps to Remove a Web Print Server .
However if is supposed to be an active Web Print server then here are some troubleshooting tips.
Web Print Service (Default Mode):
- On the server running PaperCut open services.msc, look for the service PaperCut Web Print Server and ensure this service is running.
- Try restarting the service and make a note of any errors that the OS displays.
Web Print Sandbox:
-
The Web Print dialog should be visible on the Web Print server, and the Status should not indicate any error.
-
While logged onto the Web Print server as the web print user, ensure that the mapped hot folder is accessible, has write permissions, and maps to:
\\[app-server]\[app-path]\server\data\web-print-hot-folder\
. -
While logged onto the Web Print server, open the following file in a text editor:
[app-path]\providers\web-print\[platform]\web-print.conf
Ensure thehotfolder=
option is set to the path to which you mapped the web-print-hot-folder.
Error: “The configured hot folder location is not writable.”
- Check that the location indicated by Hot folder on the Web Print dialog is correct.
- While logged in as the Web Print user, navigate to the configured Web Print Hot Folder. Try creating an empty text file. If this action fails, there is a problem with permissions. Check the Sharing and Security (NTFS/file) permissions for the Web Print Hot Folder share on the PaperCut primary server. Allow the Web Print user read and write access.
Comments