Linux Mint cannot print on Samba shared printer after password change (apparmor and authentication errors)

Written by - 0 comments

Published on September 15th 2020 - Listed in Linux


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.

Printing results in apparmor denied errors (mknod)

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":

Printer Queue held document 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:

  • Launchpad/Canonical bug 1371097 mentions a problem with missing read permissions in /var/cache/samba, however this bug was fixed.
  • Launchpad/Canonical bug 1314160 mentions the above error message, that apparmor denied cupsd from creating a file (mknod) in /var/cache/samba. This bug is still not resolved.

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?

Another apparmor error (net_admin capability)

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:

Linux printer queue authentication

But unfortunately printing still failed, however there were no apparmor errors anymore!

Credentials are not updated in printers.conf

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.


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.