Home / Alt manpages / lpmove(8)

  • lpmove(8)
  • Admin command
  • linux

Move CUPS Jobs Safely with lpmove

You will finish with a repeatable way to move one queued CUPS job, or all jobs from one source destination, to another queue. The examples use lpmove from CUPS 2.4.7, installed here as package version 2.4.7-1.2ubuntu7.14.

Allow about ten minutes for a single job and longer if you must identify several queues. You need shell access to the CUPS server, the cups-client package, the source and destination names, and permission to perform the server's move-job operation. Moving a job changes where it will print. Moving every job from a source can affect other users, so treat that form as a maintenance action and check the scope before pressing Enter.

1. Check the installed command

Start with read-only checks. These do not need elevated privileges:

$ command -v lpmove
/usr/sbin/lpmove
$ dpkg-query -W -f='${Package} ${Version}\n' cups-client
cups-client 2.4.7-1.2ubuntu7.14
$ lpmove --help
Usage: lpmove [options] job destination
       lpmove [options] source-destination destination
Options:
-E                      Encrypt the connection to the server
-h server[:port]        Connect to the named server and port
-U username             Specify the username to use for authentication

The installed help confirms two forms. The first accepts a job identifier and a new destination. The second accepts a source destination and moves all jobs from it. The manual also allows a job number on its own, or the combined form source-job, such as oldprinter-123.

Checkpoint

Write down the exact source, destination and job ID before continuing. Do not substitute the default printer for a named destination unless that is what you intend.

2. Confirm the queues and server

Use lpstat to discover queues on the server you will change:

$ lpstat -h SERVER:631 -p
printer oldprinter is idle.  enabled since ...
printer newprinter is idle.  enabled since ...

The status text is host-specific. If the scheduler is not running, or the names are absent, stop here and fix connectivity or queue configuration first. A successful lookup is not permission to move jobs, but it catches spelling errors before a state-changing command.

For a local server, omit -h SERVER:631. If you need a different CUPS server, put -h first, before the other options, as required by this installed manpage. -h selects the server; it does not create a queue or bypass authentication.

3. Move one job

Use the numeric job ID when it is unambiguous:

$ lpmove 123 newprinter
$ printf 'lpmove exit status: %s\n' "$?"
lpmove exit status: 0

Alternatively, include the old destination with the ID:

$ lpmove oldprinter-123 newprinter

The command normally prints no success message. An exit status of zero means the client completed the request; it is not a printed receipt proving that the job has finished. Check the queue afterwards:

$ lpstat -h SERVER:631 -W not-completed -o newprinter
newprinter-123  ...

Output depends on the job and server. The useful check is that the job is associated with the new destination, or that it no longer appears in the source queue. If the job has already completed, been cancelled or moved by another administrator, it may not appear in either query.

4. Move every job from a source

Only use the two-destination form after checking the complete source queue:

$ lpstat -h SERVER:631 -W not-completed -o oldprinter
oldprinter-123  ...
oldprinter-124  ...
$ lpmove oldprinter newprinter
$ printf 'lpmove exit status: %s\n' "$?"
lpmove exit status: 0

This moves all jobs from oldprinter to newprinter, not just the jobs you own. It is the most common dangerous mistake with lpmove: supplying a source destination where you meant a job identifier. Re-run lpstat for both queues and compare the result with the list you recorded.

There is no inverse command in lpmove. To undo a move, run another move for each affected job, using its current destination as the job identifier prefix and the original destination as the target:

$ lpmove newprinter-123 oldprinter

That recovery works only while the job still exists and you have identified the correct IDs. If a job has started printing, changing its destination may not stop the physical printer. Do not use lpmove as a substitute for cancel when the real requirement is to stop a job.

5. Handle authentication and encryption

Use -U to specify the username the server should authenticate:

$ lpmove -U CUPS_ADMIN 123 newprinter

Replace CUPS_ADMIN with an approved account. Do not put a password in the command line or in a script. CUPS may ask for credentials through its normal authentication flow, and the server policy decides whether the account may move jobs.

Use -E when the connection must be encrypted:

$ lpmove -E -h print.example.test:631 123 newprinter

This forces encryption when connecting to the server. It does not grant permission, and it does not validate that the destination is trustworthy. Confirm the server name and its CUPS security policy before moving jobs containing confidential documents.

6. Diagnose a failed move

A non-zero status means the request did not complete successfully. Check the exact job and queue names, then repeat the read-only lpstat queries. A missing queue, stopped scheduler, unreachable server or insufficient authorisation must be fixed at the relevant layer; adding sudo on the client is not a general solution.

The CUPS operation behind this command is CUPS-Move-Job, and server policy can require authorisation for it. If the server rejects the request, ask its administrator to inspect the configured operation policy and CUPS logs. Do not weaken policy just to make a one-off move work.

Elevated privileges are not normally required for the command itself. Use them only for a separately justified server-side repair, such as inspecting protected logs, and follow that system's change procedure. lpmove changes queued job state but does not edit printer definitions.

Done means

  • You confirmed the local cups-client and lpmove versions.
  • You checked the exact source and destination with lpstat.
  • You used the job form for one job and the source form only when moving all source jobs was intended.
  • You checked the exit status and inspected the resulting queues.
  • You know how to move an affected job back while it still exists.
  • You did not expose credentials, weaken CUPS policy or assume that sudo fixes a server-side denial.