You connect a printer and nothing happens
You plug a USB printer into your Fedora machine and expect it to work instantly. Instead, the Settings app shows an empty list, or your documents queue up and vanish without a single page coming out. You run systemctl status cups and see it inactive. Or worse, it says active but the printer still refuses to talk to the system. This is a common friction point when moving from Windows or macOS. The underlying printing stack is different, and Fedora expects you to manage the service and drivers explicitly. Run the service first. A dead daemon explains every missing queue.
How CUPS actually routes your jobs
Fedora relies on CUPS, the Common Unix Printing System. CUPS acts as a middleware layer between your applications and the physical hardware. When you click print in a browser or document editor, the application hands the job to CUPS. CUPS translates the job into a language the printer understands, manages the queue, and sends the data over USB, Ethernet, or Wi-Fi. The system splits this into three moving parts. The daemon handles the queue and translation. The driver or filter converts the job format. The backend handles the physical transport. If any piece is missing or misconfigured, the job stalls. Think of it like a postal service. CUPS is the sorting facility. The driver is the translator who converts your letter into the destination country's language. The backend is the delivery truck. You need all three aligned before the mail moves.
CUPS uses a modular pipeline. The scheduler receives the job, passes it through a filter chain that converts PDF or PostScript into raster data, and hands the result to a backend like usb, socket, or ipp. The backend opens the communication channel and streams the bytes to the device. Modern Fedora installations ship with cups-filters, which provides the translation layer. If you install a proprietary driver from the manufacturer, it usually drops a PPD file and a custom filter into the CUPS directory. The scheduler reads the PPD to understand what the printer supports, then routes the job accordingly. Check the pipeline before you guess. Run cupsctl and lpstat to see what the system actually loaded.
Start the service and enable discovery
Fedora disables the printing service by default on minimal installs to save resources. You must activate it before any hardware detection works. Run the following to start the daemon and register it for boot.
sudo systemctl enable --now cups # Enable the service and start it immediately
sudo systemctl enable --now cups-browsed # Enable automatic discovery of network printers
sudo systemctl status cups # Verify the service is active and running
The cups-browsed package listens for printers advertised via mDNS or DNS-SD on your local network. It bridges modern network printers into the CUPS queue automatically. Once the service is live, check whether the system already detected your hardware.
lpstat -p -d # List available printers and show the default destination
lpinfo -m # Show available driver filters and PPD models
lpinfo -v # List detected device URIs for USB and network backends
If your printer appears in the lpstat output, you can skip to verification. If it is missing, you need to add it manually. Fedora ships with system-config-printer, which works in both terminal and GUI environments. It handles driver matching better than raw CUPS commands.
sudo dnf install system-config-printer # Install the configuration utility if missing
sudo system-config-printer # Launch the interactive setup wizard
The wizard will scan for USB, network, and wireless devices. Select your printer from the list. When prompted for a driver, choose the manufacturer-specific option if available. If you see a generic "Generic PCL" or "IPP Everywhere" option, pick that instead. Modern printers handle formatting internally, and generic drivers reduce compatibility headaches. Confirm the queue name and finish the setup. Enable discovery before you add devices. A silent network hides half the printers on your LAN.
Verify the queue and test the output
Do not assume the printer is ready because it shows up in the list. Send a test job and watch the queue status.
lp -d <printer_name> /usr/share/cups/data/testprint # Send the standard CUPS test page
lpq -P <printer_name> # Check the queue status for that specific printer
You should see the job move from ready to processing and then disappear as the printer finishes. If the job stays stuck in stopped or held, check the error log. CUPS writes detailed diagnostics to the journal.
journalctl -u cups -n 20 --no-pager # Show the last 20 lines of the CUPS service log
journalctl -u cups-browsed -n 10 --no-pager # Check discovery service logs for network printers
Look for lines mentioning filter failed, backend error, or permission denied. The log tells you exactly which stage broke. Reboot before you debug. Half the time the symptom is gone after a fresh USB enumeration or network handshake.
Common pitfalls and what the error looks like
The most frequent blocker is the firewall. CUPS listens on port 631 for local and network management. If you recently enabled firewalld, it may be blocking printer discovery or remote queue access.
sudo firewall-cmd --list-services # Check which services are allowed through the firewall
sudo firewall-cmd --add-service=ipp --permanent # Allow IPP printer protocol permanently
sudo firewall-cmd --reload # Apply the rule to the running firewall immediately
SELinux is another silent blocker. If you see Permission denied in the CUPS log but the user has root privileges, SELinux is likely enforcing a policy that prevents the daemon from accessing the USB device or network socket. Check the audit log for the exact denial.
sudo ausearch -m avc -ts recent | grep cups # Search for recent SELinux denials related to CUPS
sudo sealert -a /var/log/audit/audit.log # Analyze the audit log and suggest fixes
Driver mismatches cause another class of failures. You might see the following error in the journal when the filter chain cannot parse the job:
E [15/Oct/2024:10:23:41 +0000] [Job 14] Filter "tops" failed: /usr/lib/cups/filter/pstops: error while loading shared libraries: libpaper.so.1: cannot open shared object file
This specific error means a required library is missing or the driver expects a different architecture. Install the missing dependency with dnf or switch to an IPP Everywhere driver. Never edit files in /usr/lib/cups/. Those paths ship with the package and get overwritten on updates. Place custom filters or PPD overrides in /etc/cups/ instead. Trust the package manager. Manual file edits drift, snapshots stay.
Network and wireless printers add another layer of complexity. If your printer uses a static IP address, cups-browsed will not find it automatically. You must add it manually using the socket:// backend.
sudo lpadmin -p <printer_name> -E -v socket://192.168.1.50:9100 -m everywhere # Create a queue for a static IP printer
sudo cupsenable <printer_name> # Enable the queue for incoming jobs
sudo cupsaccept <printer_name> # Accept jobs from all users
The everywhere model tells CUPS to rely on the printer's internal firmware for formatting. This bypasses PPD dependencies entirely. Use static IP configuration when your network does not support mDNS broadcasting. A reliable IP address beats discovery protocols every time.
When to use this vs alternatives
Use the GNOME Settings app when you want a visual interface to browse available printers and preview driver options. Use system-config-printer when you need fine-grained control over queue settings, duplex modes, or paper trays. Use the cupsaddsprinter command when you are scripting printer deployment across multiple machines or working on a headless server. Use IPP Everywhere drivers when your printer supports modern protocol standards and you want to avoid proprietary PPD files. Stay on the default CUPS configuration if you only print occasionally and do not need advanced queue management.