Reopen a CUPS Printer Queue with cupsaccept

You will allow new print jobs to enter a CUPS destination, then check that the destination is accepting jobs. The command changes printer-server state, so allow about five minutes and confirm the destination name before running it. This guide uses cupsaccept from the Debian package cups-client, version 2.4.7-1.2ubuntu7.14, installed on this machine.

You need a shell, a reachable CUPS server and permission to administer the destination. Depending on the server configuration, CUPS may ask for an access password. The examples use PRINTER_NAME as a placeholder. Replace it with the exact printer or class name from your own system.

1. Check the installed command and destination

Start with read-only checks. These do not change the queue:

$ command -v cupsaccept
/usr/sbin/cupsaccept
$ dpkg-query -W -f='${Package} ${Version}\n' cups-client
cups-client 2.4.7-1.2ubuntu7.14
$ lpstat -p -d
printer PRINTER_NAME is idle.  enabled since ...
system default destination: PRINTER_NAME

Your lpstat output will differ. If it lists no destinations, stop here and identify the printer or class through the normal CUPS administration process. Do not guess a name. CUPS names are not case-sensitive, but they cannot contain a space, tab, slash or hash character according to the installed manual.

Checkpoint: you should have an exact destination name and know which CUPS server owns it.

2. Understand what accepting means

CUPS keeps two separate pieces of queue state. A destination can accept new jobs while its printer is disabled, or it can be enabled while new jobs are rejected. cupsaccept changes only whether new jobs may be submitted to the destination. It does not enable the printer, start a stopped device, release a held job or print anything already queued.

That distinction is the main trap in this command. If jobs are already accepted but are not being processed, investigate the printer's enabled state and scheduler separately. If the queue was deliberately stopped for maintenance, accepting jobs again may make the backlog grow while the printer remains unavailable.

3. Accept jobs on the local CUPS server

Run the command with the destination as its final argument:

$ cupsaccept PRINTER_NAME

A successful invocation normally produces no output. Check the exit status immediately if you need a machine-readable result:

$ cupsaccept PRINTER_NAME
$ printf 'cupsaccept exit status: %s\n' "$?"
cupsaccept exit status: 0

Exit status zero means the request was accepted by the command. It is still worth checking the server's view of the queue, especially when several CUPS servers or printers have similar names:

$ lpstat -p PRINTER_NAME -l
printer PRINTER_NAME is idle.  enabled since ...
	Accepting Requests: Yes

The exact status wording and timestamp are supplied by your local CUPS tools. The useful confirmation is that the destination reports that it is accepting requests.

4. Target another CUPS server

Use -h when the destination belongs to a different server or port. The host and optional port are passed as one value:

$ cupsaccept -h print-server.example:631 PRINTER_NAME

This is an administrative change on the selected server, not necessarily on the server named by your local CUPS configuration. Verify the remote state explicitly:

$ lpstat -h print-server.example:631 -p PRINTER_NAME -l
printer PRINTER_NAME is idle.  enabled since ...
	Accepting Requests: Yes

Use the real host name or address supplied by your printing administrator. If the server requires encrypted transport, add -E:

$ cupsaccept -E -h print-server.example:631 PRINTER_NAME

The -E option forces encryption for the connection. It does not create a certificate, fix server TLS configuration or make an untrusted server safe.

5. Supply an identity when the server requires it

Some configurations need a username for authentication. Pass it with -U and let CUPS handle any password prompt:

$ cupsaccept -U ADMIN_USER -h print-server.example:631 PRINTER_NAME

Do not put a password in the command line. Command arguments can be visible to other local users and may be recorded in shell history or process diagnostics. If authentication fails, check the account's CUPS permissions and the server name rather than repeatedly retrying with guessed credentials. Elevated privileges on the client do not automatically grant permission on a remote CUPS server.

6. Recover if accepting was premature

Acceptance is reversible, but reversing it also changes live queue policy. Warn anyone who may be submitting jobs before you reject new work again:

$ cupsreject PRINTER_NAME
$ lpstat -p PRINTER_NAME -l
printer PRINTER_NAME is idle.  enabled since ...
	Rejecting Requests: Yes

cupsreject is the companion command. It prevents new submissions but does not remove jobs already in the queue. Do not use cancel -a as an undo: that is a separate, destructive action which cancels queued jobs.

To restore normal operation later, run cupsaccept PRINTER_NAME again and verify the accepting state. If you only intended to stop printing while keeping submissions queued, investigate cupsenable and cupsdisable instead; do not use acceptance controls as a substitute for printer controls.

Common failure modes

• Unknown destination: the name may belong to another server, contain a typo, or be a class rather than a printer. Recheck it with lpstat and repeat with the correct -h value.
• Permission denied: the CUPS server rejected the operation. Check the configured administrator identity and authentication policy. Do not assume sudo will solve a remote authorisation failure.
• Jobs still do not print: accepting requests only opens the input side of the queue. Check whether the destination is enabled, whether the scheduler is running, and whether the device or connection has a separate fault.
• Unexpected backlog: the queue may have been closed intentionally. Review queued jobs and tell users before reopening it. Keep the original policy in your change record.