When using CUPS from the command line this error may occur after adjusting the default cupsd.conf

~ # cupsdisable LP1234
cupsdisable: Operation failed: cups-authorization-canceled
~ # cupsdisable -h localhost:631 LP1234
cupsdisable: Operation failed: cups-authorization-canceled
~ # cupsdisable -h localhost:631 -U root LP1234
cupsdisable: Operation failed: cups-authorization-canceled

If debug logging is enabled there may be entries like the following in your cups logs

D [24/Jan/2012:14:58:57 -0500] cupsdAcceptClient: 16 from localhost:631 (IPv6)
D [24/Jan/2012:14:58:57 -0500] cupsdReadClient: 16 POST /admin/ HTTP/1.1
D [24/Jan/2012:14:58:57 -0500] cupsdSetBusyState: newbusy="Active clients and dirty files", busy="Dirty files"
D [24/Jan/2012:14:58:57 -0500] cupsdAuthorize: No authentication data provided.
D [24/Jan/2012:14:58:57 -0500] cupsdIsAuthorized: username=""
D [24/Jan/2012:14:58:57 -0500] cupsdSendHeader: 16 WWW-Authenticate: Basic realm="CUPS", trc="y"
D [24/Jan/2012:14:58:57 -0500] cupsdCloseClient: 16
D [24/Jan/2012:14:58:57 -0500] cupsdSetBusyState: newbusy="Dirty files", busy="Active clients and dirty files"

Likely Causes & Solutions

This is really not that terrible, it likely means the cupsd.conf file has some too-strict security settings. Edit the file and pay special attention to the Location /admin section.

This example allows only access from the localhost user to do admin stuff, and only from localhost

<Location /admin>
    Order allow,deny
    Allow 127.0.0.1
</Location>

The important thing to understand for CUPS is that policy for requests is set further below, in the <Policy> sections. Don't try to over do the security in the Location sections.