Although printing on Linux has seen a major improvement (in parallel of the Linux Desktop) in the past 10 years, there are still some issues - and it doesn't even have to be the printer's fault. In this particular situation, printing from Linux Mint 19.3 on a (Samba) shared printer on a print server (which requires authentication), stopped working.
Important note: All of these problems happened, after the password of the workgroup user was changed.
When trying to print a document (a simple Spreadsheet from Libreoffice), the printer asked for authentication (due to the changed password). After entering the new credentials, printing still failed. The document remained in the print queue with a status "Held for authentication":
By looking at dmesg, a lot of apparmor errors caught my eye:
admck@mint:~$ dmesg | tail -n 3
[ 6087.994578] audit: type=1400 audit(1600150006.092:113): apparmor="DENIED" operation="mknod" profile="/usr/sbin/cupsd" name="/var/cache/samba/gencache.tdb" pid=9316 comm="smb" requested_mask="c" denied_mask="c" fsuid=7 ouid=7
[ 6087.994941] audit: type=1400 audit(1600150006.096:114): apparmor="DENIED" operation="mknod" profile="/usr/sbin/cupsd" name="/var/cache/samba/gencache.tdb" pid=9316 comm="smb" requested_mask="c" denied_mask="c" fsuid=7 ouid=7
[ 6088.022552] audit: type=1400 audit(1600150006.120:115): apparmor="DENIED" operation="mknod" profile="/usr/sbin/cupsd" name="/var/cache/samba/gencache.tdb" pid=9316 comm="smb" requested_mask="c" denied_mask="c" fsuid=7 ouid=7
Interestingly, these apparmor errors for the cups daemon (/usr/sbin/cupsd) are nothing new:
By looking at the relevant apparmor ruleset, it shows that cupsd only has read permissions for tbd files within /var/cache/samba, but no write permissions:
admck@mint:~$ cat /etc/apparmor.d/usr.sbin.cupsd | grep samba
deny /{,var/}run/samba/ rw,
/{,var/}run/samba/** rw,
/var/cache/samba/*.tdb r,
/var/{cache,lib}/samba/printing/printers.tdb r,
To fix this, the cupsd apparmor profile can be extended with a "local" apparmor rule:
admck@WM2856L:~$ sudo su -
root@WM2856L:~# echo "/var/cache/samba/*.tdb rw," >> /etc/apparmor.d/local/usr.sbin.cupsd
After this, apparmor needs to be told to re-read the cupsd profile:
admck@mint:~$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.cupsd
Printing should now work, right?
After releasing the held document in the print queue, the following log entries were logged:
admck@mint:~$ tail -f /var/log/kern.log /var/log/cups/error_log /var/log/cups/access_log
==> kern.log <==
Sep 15 08:22:21 WM2856L kernel: [ 7022.885726] audit: type=1400 audit(1600150941.018:145): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2745 comm="cupsd" capability=12 capname="net_admin"
==> cups/access_log <==
localhost - - [15/Sep/2020:08:22:21 +0200] "POST /jobs/ HTTP/1.1" 200 167 Set-Job-Attributes successful-ok
==> cups/error_log <==
E [15/Sep/2020:08:22:21 +0200] [Job 20] Session setup failed: NT_STATUS_LOGON_FAILURE
E [15/Sep/2020:08:22:21 +0200] [Job 20] Session setup failed: NT_STATUS_INTERNAL_ERROR
E [15/Sep/2020:08:22:21 +0200] [Job 20] Session setup failed: NT_STATUS_LOGON_FAILURE
E [15/Sep/2020:08:22:21 +0200] [Job 20] Session setup failed: NT_STATUS_ACCESS_DENIED
==> kern.log <==
Sep 15 08:22:21 WM2856L kernel: [ 7023.466958] audit: type=1400 audit(1600150941.598:146): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2745 comm="cupsd" capability=12 capname="net_admin"
Sep 15 08:22:21 WM2856L kernel: [ 7023.501060] audit: type=1400 audit(1600150941.634:147): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2745 comm="cupsd" capability=12 capname="net_admin"
Sep 15 08:22:21 WM2856L kernel: [ 7023.510201] audit: type=1400 audit(1600150941.642:148): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=2745 comm="cupsd" capability=12 capname="net_admin"
This time apparmor asked for the net_admin capability for cupsd. And yet again, this is nothing new. Launchpad/Canonical bug 1660316 mentions this error and is still open.
To fix this, the same local apparmor file from before can be used again. The net_admin capabilities are simply appended to this file:
admck@mint:~$ sudo su -
root@mint:~# echo "capability net_admin," >> /etc/apparmor.d/local/usr.sbin.cupsd
Followed by another apparmor reload of the cupsd profile:
admck@mint:~$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.cupsd
Next try! Release the held documents again and enter credentials:
But unfortunately printing still failed, however there were no apparmor errors anymore!
Now with the apparmor errors gone, there must definitely be a problem with the credentials. Or is there? The entered credentials were triple-checked - they were correct. Yet cups clearly logged authentication errors on the NT domain:
==> cups/access_log <==
localhost - - [15/Sep/2020:08:28:36 +0200] "POST /jobs/ HTTP/1.1" 200 167 Set-Job-Attributes successful-ok
==> cups/error_log <==
E [15/Sep/2020:08:28:36 +0200] [Job 20] Session setup failed: NT_STATUS_LOGON_FAILURE
E [15/Sep/2020:08:28:36 +0200] [Job 20] Session setup failed: NT_STATUS_INTERNAL_ERROR
E [15/Sep/2020:08:28:36 +0200] [Job 20] Session setup failed: NT_STATUS_LOGON_FAILURE
E [15/Sep/2020:08:28:36 +0200] [Job 20] Session setup failed: NT_STATUS_ACCESS_DENIED
The reason is actually quite simple: The credentials were hard-coded into the printer settings (DeviceURI):
admck@mint:~$ sudo cat /etc/cups/printers.conf
# Printer configuration file for CUPS v2.2.7
# Written by cupsd
# DO NOT EDIT THIS FILE WHEN CUPSD IS RUNNING
UUID urn:uuid:3012893d-2ef4-354b-43f5-7ade55976c9b
AuthInfoRequired username,password
Info Generic PCL 6
MakeModel Generic PCL 6 Printer wide margin - CUPS+Gutenprint v5.2.13
DeviceURI smb://domain%5Cuser:password@printserver.local/PullPrint_PCL
State Idle
StateTime 1600151711
ConfigTime 1588083087
Type 4116
Accepting Yes
Shared Yes
JobSheets none none
QuotaPeriod 0
PageLimit 0
KLimit 0
OpPolicy default
ErrorPolicy retry-job
After the credentials were adjusted in /etc/cups/printers.conf (as root), cups was restarted and another release of the held document was attempted.
admck@mint:~$ sudo vi /etc/cups/printers.conf (adjust password)
admck@mint:~$ sudo systemctl restart cups
This time it finally worked: The document was sent to the printer!
All cups logged in this case was a successful POST on the jobs:
localhost - - [15/Sep/2020:08:42:56 +0200] "POST /jobs/ HTTP/1.1" 200 167 Set-Job-Attributes successful-ok
Finally success, although it is not cool that all these relevant cups bugs are still open in Ubuntu.
I got another error from CUPS when I tried to change the printer properties.
After a click on "Apply", a user/password prompt was shown and asked for credentials. Neither the credentials of my own user nor the root user worked.
To find out more, the logs need to be analyzed:
ckmint /etc/cups $ sudo tail -f /var/log/cups/error_log
==> /var/log/cups/error_log <==
E [13/Apr/2024:09:45:15 +0200] [Client 177] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/MFC9330CDW) from localhost
E [13/Apr/2024:09:45:22 +0200] [Client 182] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/MFC9330CDW) from localhost
E [13/Apr/2024:09:45:24 +0200] [Client 186] pam_authenticate() returned 7 (Authentication failure)
E [13/Apr/2024:09:45:26 +0200] [Client 189] pam_authenticate() returned 7 (Authentication failure)
E [13/Apr/2024:09:45:32 +0200] [Client 193] pam_authenticate() returned 7 (Authentication failure)
E [13/Apr/2024:09:45:34 +0200] [Client 196] pam_authenticate() returned 7 (Authentication failure)
E [13/Apr/2024:09:46:54 +0200] [Client 206] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/MFC9330CDW) from localhost
E [13/Apr/2024:09:46:56 +0200] [Client 210] pam_authenticate() returned 7 (Authentication failure)
E [13/Apr/2024:09:46:58 +0200] [Client 213] pam_authenticate() returned 7 (Authentication failure)
E [13/Apr/2024:09:47:38 +0200] [Client 218] Returning HTTP Forbidden for CUPS-Add-Modify-Printer (ipp://localhost/printers/MFC9330CDW) from localhost
The settings are stored in /etc/cups/printers.conf and only root can write that file:
ck@mint /etc/cups $ ls -la
total 108
drwxr-xr-x 5 root lp 4096 Apr 13 09:45 .
drwxr-xr-x 209 root root 12288 Apr 12 06:58 ..
-rw------- 1 root lp 108 Feb 8 2020 classes.conf
-rw------- 1 root lp 108 Sep 18 2019 classes.conf.O
-rw-r--r-- 1 root root 30850 May 15 2023 cups-browsed.conf
-rw-r--r-- 1 root root 4630 Nov 24 2017 cupsd.conf
-rw-r--r-- 1 root root 2860 Sep 15 2023 cups-files.conf
drwxr-xr-x 2 root root 4096 Aug 23 2017 interfaces
drwxr-xr-x 2 root lp 4096 Apr 13 09:44 ppd
-rw------- 1 root lp 966 Apr 13 09:45 printers.conf
-rw------- 1 root lp 966 Apr 13 09:43 printers.conf.O
-rw-r--r-- 1 root root 240 Nov 24 2017 raw.convs
-rw-r--r-- 1 root root 211 Nov 24 2017 raw.types
-rw-r--r-- 1 root root 142 Aug 23 2017 snmp.conf
drwx------ 2 root lp 4096 Nov 24 2017 ssl
-rw-r----- 1 root lp 1276 Apr 13 09:45 subscriptions.conf
-rw-r----- 1 root lp 1030 Apr 13 09:43 subscriptions.conf.O
After changing the permissions with chmod and additionally adding my own local user to the lpadmin group, I was able to change (and save) the printer properties.
ck@mint /etc/cups $ sudo chmod 666 printers.conf*
ck@mint /etc/cups $ sudo usermod -a -G lpadmin ckadm
Bert from Netherlands wrote on Mar 21st, 2022:
I have been struggling with this issue for a few months also (I am rather new to Linux, installed Linux Mint in december 2021). I did manage to setup a samba server with two network shared printers that I could eventually print to from Windows 10, but so far it refused to accept printer connections from a Linux(Mint) client. I fixed it mainly by filling in the domain (workgroup) + username + password in the printers.conf file. I only fixed the first apparmor error, didn't bother with the second error since that didn't seem to do the trick for you either. After all it works now, also without fixing the other apparmor errors.
Thanks a lot.
It's a real shame that this kind of errors keep coming up, because it probably puts a lot of people off Linux and towards Microsoft Windows (10).
CUPS HATER from wrote on Feb 19th, 2021:
Thank You sooo much!
I have bin struggling with this idiotizm for years.
I do not have password needed for my network printer, but I need to apply Your fix, just to enter empty password. Now it works.
AWS Android Ansible Apache Apple Atlassian BSD Backup Bash Bluecoat CMS Chef Cloud Coding Consul Containers CouchDB DB DNS Database Databases Docker ELK Elasticsearch Filebeat FreeBSD Galera Git GlusterFS Grafana Graphics HAProxy HTML Hacks Hardware Icinga Influx Internet Java KVM Kibana Kodi Kubernetes LVM LXC Linux Logstash Mac Macintosh Mail MariaDB Minio MongoDB Monitoring Multimedia MySQL NFS Nagios Network Nginx OSSEC OTRS Observability Office OpenSearch PGSQL PHP Perl Personal PostgreSQL Postgres PowerDNS Proxmox Proxy Python Rancher Rant Redis Roundcube SSL Samba Seafile Security Shell SmartOS Solaris Surveillance Systemd TLS Tomcat Ubuntu Unix VMWare VMware Varnish Virtualization Windows Wireless Wordpress Wyse ZFS Zoneminder