cups-pdf fails to generate file when user does not print to default ~/PDF (apparmor vs.cups-pdf inconsistency)

[Alexander Hunziker]

I had a working cups-pdf setup in Feisty, but after the upgrade to Gutsy it doesn't work anymore.

The log file says:

Mon Oct 1 10:05:49 2007 [STATUS] PDF creation successfully finished (nobody)
Mon Oct 1 10:14:51 2007 [ERROR] failed to set file mode for PDF file (non fatal) (/home/hunzikea/Desktop/Report_a_bug.pdf)
Mon Oct 1 10:14:51 2007 [STATUS] PDF creation successfully finished (hunzikea)

[Till Kamppeter (till-kamppeter)]

Probably the AppArmor protection of CUPS prevents the generation of the PDF. Please update your system to have the newest CUPS (at least 1.3.2-1ubuntu1).

[Alexander Hunziker (alex-hunziker)]

I already do have the latest version of CUPS.

[Gert Kulyk (gkulyk)]

One line in your post may explain why it fails: The default (and therefore allowed by apparmor) place for created pdf's is $(HOME)/PDF. If this directory is not used (or is a symlink, just to add this), that means you've changed the default path in cups-pdf.conf, you'll need to apply this changes in the /etc/apparmor.d/usr.sbin.cupsd file, too.
The line:
> Mon Oct 1 10:14:51 2007 [ERROR] failed to set file mode for PDF file (non fatal)
> (/home/hunzikea/Desktop/Report_a_bug.pdf)
leeds me to the assumption, you did change the default-location for pdfs stored by cups-pdf, but you've forgotten to modify usr.sbin.cupsd-file to reflect these changes. If you e.g. want the created pdf-files to be placed on the Desktop, you'll need to change the lines:

 @{HOME}/PDF/ w,
 @{HOME}/PDF/* w,

into:

 @{HOME}/Desktop/ w,
 @{HOME}/Desktop/* w,

in the mentioned usr.sbin.cupsd file and restart the apparmor-service.

[Martin-Éric Racine (q-funk)]

On 10/3/07, Gert Kulyk <email address hidden> wrote:
> One line in your post may explain why it fails: The default (and therefore allowed by apparmor) place for created pdf's is $(HOME)/PDF. If this directory is not used (or is a symlink, just to add this), that means you've changed the default path in cups-pdf.conf, you'll need to apply this changes in the /etc/apparmor.d/usr.sbin.cupsd file, too.
> The line:
> > Mon Oct 1 10:14:51 2007 [ERROR] failed to set file mode for PDF file (non fatal)
> > (/home/hunzikea/Desktop/Report_a_bug.pdf)
> leeds me to the assumption, you did change the default-location for pdfs stored by cups-pdf, but you've forgotten to modify usr.sbin.cupsd-file to reflect these changes. If you e.g. want the created pdf-files to be placed on the Desktop, you'll need to change the lines:
>
> @{HOME}/PDF/ w,
> @{HOME}/PDF/* w,
>
> into:
>
> @{HOME}/Desktop/ w,
> @{HOME}/Desktop/* w,
>
> in the mentioned usr.sbin.cupsd file and restart the apparmor-service.

You found the real bug. Well done!

Till: would it make more sense to put that AppArmor segment into the
cups-pdf package, so that we could modify it as the package evolve and
also document it as a part of cups-pdf, in case people decide to
select a non-default output path?

[Till Kamppeter (till-kamppeter)]

Gert Kulyk, good idea with moving the AppArmor config to cups-pdf. This improves the maintainability a lot.

Pitti, is this possible without any problems?

[Till Kamppeter (till-kamppeter)]

The next release of the cups-pdf and cupsys packages will allow ~/Desktop as PDF destination directory and use it as the default.

[Gert Kulyk (gkulyk)]

I've posted a possible cause for the mentioned behavior, the idea is from Martin-Éric Racine :-).

[Till Kamppeter (till-kamppeter)]

Martin, Gert, sorry, cut-and-paste mistake.

[Martin-Éric Racine (q-funk)]

On 10/3/07, Till Kamppeter <email address hidden> wrote:
> Martin, Gert, sorry, cut-and-paste mistake.

No problemo. :)

[Till Kamppeter (till-kamppeter)]

I have withdrawn the proposed fix of moving the output to the ~/Desktop directory (and allowing cups-pdf to write to there) as this will have several problem. Users can configure another directory to be displayed on the desktop and also they could not like the desktop being cluttered by the generated PDFs. So we will leave the destination being "~/PDF", as no known application is using this directory.

The only solution in our environment with AppArmor-protected CUPS would be to have a user tool for changing the destination directory which changes both the cups-pdf and AppArmor config files and then we would have the problem of a tool running as an arbitrary normal user modifying the configuration of a central security subsystem. In general, a major redesign of the PDF generator CUPS queue concept by upstream would be needed for which it is too late to include it in Gutsy.

In general it is a much better solution to have the applications by themselves generating PDFs via "File"/"Export to PDF ..." or "File"/"Print ...". OpenOffice.org has "File"/"Export to PDF ..." and the current printing dialogs of both KDE and GNOME have functionality to print into a PDF file, actually saving it as PDF, asking the user for name and location. This is the most intuitive way and does not involve any system process which runs with other rights than the calling user, so it gives also the maximum security.

cups-pdf is an interim solution for all the apps which did not yet adopt the latest printing dialogs (especially Firefox and Thunderbird). So we will remove cups-pdf from Ubuntu as soon as all apps have caught up. In the mean time we will only sync with upstream and fix bugs.

The real bug is in the apps which do not use the current printing dialogs.

[Martin-Éric Racine (q-funk)]

On 10/4/07, Till Kamppeter <email address hidden> wrote:
> I have withdrawn the proposed fix of moving the output to the ~/Desktop
> directory (and allowing cups-pdf to write to there) as this will have
> several problem.

Agreed.

> cups-pdf is an interim solution for all the apps which did not yet adopt
> the latest printing dialogs (especially Firefox and Thunderbird). So we
> will remove cups-pdf from Ubuntu as soon as all apps have caught up. In
> the mean time we will only sync with upstream and fix bugs.

Actually, no. CUPS-PDF fulfills a much bigger role than playing
stop-gap for applications not integrated with GNOME or KDE. It's also
extremely useful as a way of receiving files from a variety of command
line tools and daemons and making PDF content out of that. Thus,
removing it once legacy apps have caught up with direct CUPS
interfacing is not a good idea, since it actually has uses beyond
desktop environments.

--
Martin-Éric Racine
http://q-funk.iki.fi

[NoOp (glgxg)]

After today's updates, I found that none of my cups-pdf printers work on any of my Gutsy systems. I resolved the problem by:

$ sudo apt-get remove --purge apparmor apparmor-utils

IMHO apparmor should not be installed by default (it was optional in Feisty). Added apparmor info:
https://launchpad.net/ubuntu/+source/apparmor/+bugs
https://wiki.ubuntu.com/AppArmor
http://en.opensuse.org/Apparmor

Related bugs cups-pdf bugs that are apparmor created/related:
https://bugs.launchpad.net/ubuntu/+source/cups-pdf/+bug/134682

[Till Kamppeter (till-kamppeter)]

NoOp, AppArmor is installed by default as a new security concept for CUPS, replacing the old, ugly patches making CUPS running as a non-root user (which are not supported upstream). As cups-pdf is called by CUPS, the AppArmor profile of CUPS also applies to cups-pdf.

Martin-Éric Racine, cups-pdf is not really needed to create PDFs out of scripts. You can call all filters, like pstopdf, ps2pdf, dvipdf, convert (ImageMagick), ... directly from the command line, even the CUPS filters in /usr/lib/cups/filter/. From CUPS 1.3 on you can even use the full file conversion logic of CUPS using the "cupsfilter" command (see "man cupsfilter"). Then everything is executed with the rights of the user who calls the script and so any problems of security or file permissions are avoided.

[NoOp (glgxg)]

> NoOp, AppArmor is installed by default as a new security concept for
> CUPS, replacing the old, ugly patches making CUPS running as a non-root
> user (which are not supported upstream). As cups-pdf is called by CUPS,
> the AppArmor profile of CUPS also applies to cups-pdf.
>

Thanks for the info, I'll add apparmor back in. I also notice that
todays updates include some reversals/changes for cups/cups-pdf so I'll
load apparmor before applying those new updates.

[NoOp (glgxg)]

Added apparmor back in, installed all of todays Gutsy updates (Accepted cups-pdf 2.4.6-3ubuntu9 (source)) etc., and print to cups-pdf to /PDF worked. I then changed /etc/cups/cups-pdf.conf to print to an alternate directory /PDFPrinter (Out ${HOME}/PDFPrinter), and printing failed. Var log for cups-pdf shows:

Fri Oct 5 11:56:02 2007 [ERROR] failed to create directory (/root/PDFPrinter)
Fri Oct 5 11:56:02 2007 [ERROR] failed to create user output directory (/root/PDFPrinter)

Removing apparmor allowed the cups-pdf print job to go to the existing /PDFPrinter directory.

Changing cups-pdf.conf again to Out ${HOME}/PDFPrint (without creating a /PDFPrint directory first), then printing: 1) created the directory, and 2) printed the PDF in the newly created /PDFPrint directory. Is this the security issue that apparmor is to protect against? If so, is there a way to sync the apparmor profile with cups-pdf.conf?

As an added note: I notice that the printer icon now stays in the panel following any first print job. Previously it disappeared after the print job was finished. Is this something new/expected, or is it a bug?

[Till Kamppeter (till-kamppeter)]

The printer icon is another implementation now. It is provided by system-config-printer and not by gnome-cups-manager any more. system-config-printer replaces gnome-cups-manager because gnome-cups-manager is not maintained any more upstream. system-config-printer is developed very actively. In system-config-printer the icon stays if it once appeared, but it is grayed out if the local print queues are empty.

It looks like that you are trying to generate PDF files by printing files as root (destination /root/PDFPrinter). Perhaps AppArmor can only cope with /home/$USER/ home directories. Try as normal user at first.

Syncing the AppArmor profile with the PDF destination is difficult, once because only root can change the AppArmor configuration and normal users change their PDF destinations and second, every user can set his PDF destination independently, to a different place. The AppArmor profile opens up only one place.

[stefangachter (stefan-gachter)]

Please, can anybody help. I delete Ubuntu 7.04 and installed 7.10 and now I have exactly this problem. So, I followed the steps above.

My /etc/cups/cups-pdf.conf entry:

Out ${HOME}/Download

My /etc/apparmor.d/usr.sbin.cupsd entries:

  @{HOME}/Download/ w,
  @{HOME}/Download/* w,

I restarted the whole system but I still get the error:

Wed Oct 24 07:01:45 2007 [ERROR] failed to set file mode for PDF file (non fatal) (/home/stefangachter/Download/job_19-035.pdf)

Do I have to change something else? Did I do something wrong?

I cannot find any pdf file. Even with the standard configuration, no pdf file is created. Under 7.04 it worked perfectly but now it is a total mystery.

Please, can anybody help... why doesn't it work in my case?

Thanks a lot, Stefan

[stefangachter (stefan-gachter)]

Sorry for my pleading... in a final attempt, I restarted my system again. Restarting the services seems not to be enough. And now it works. BUT, only if I do a printout from an application. If I use the "Print Test Page" button, in the printer configuration, nothing happens. I had this problem in 7.04 already. The "Print Test Page" button did and does not work properly, because it does not consider the current CUPS configuration! Is this kind of a joke?

[JSladek (wb4ubd)]

The same thing happened to me, however, I found the "PrintTest Page" file in /var/spool/cups-pdf/ANONYMOUS. I have no idea how this happens and how to work around it.

[stefangachter (stefan-gachter)]

Yes, indeed, all the test-page-files ended up in /var/spool/cups-pdf/ANONYMOUS instead of the specified directory...

[Till Kamppeter (till-kamppeter)]

How did you send the test page to the PDF printer? If you send it from system-config-printer (the standard printer setup tool in Ubuntu Gutsy) from hp-toolbox (HP printers only) or by simply printing the file /usr/share/cups/data/testprint.ps the PDF should arrive in the ~/PDF directory, as the job is sent with your user identity. If you send it from the CUPS web interface the job is not sent with your user identity, as web applications usually do not run with the identity of the user who runs the browser (in most cases the application runs on another machine). The CUPS web interface for example runs as root or lp (I am not sure which user exactly) and the job of printing the test page gets sent with that identity. cups-pdf seems to handle jobs from system users as anonymous. Applications where you get asked for your password before you see the main window or with an "administrator mode" which asks for the password run completely as root and therefore test printouts from them will also go into the directory for anonymous jobs.

[stefangachter (stefan-gachter)]

I understand, however, in my case, I sent the test pages from system-config-printer (System -> Administration -> Printing) and they ended up in anonymous. So, there is something "wrong".

What you described above makes sense from a sys admin point of view, however, from user point of view, it can be quiet annoying, because different applications have a different printing behaviors, depending on their "mode". Would be nice to have something more consistent in future...

[JSladek (wb4ubd)]

I concur 100% with stefangachter. As far as I can see, the only item showing up in anonymous is the Test Page from the printer setup tool - which inconsistent with the Kamppeter discussion.

[modred (bobanderson)]

I tried to change the output directory to 'autosave' from 'PDF' by changing the /etc/apparmor.d/usr.sbin.cupsd and /etc/cups/cups-pdf.conf files and rebooting. A PDF file is not created and the kernel log shows the following:

Oct 30 11:53:47 dell kernel: [ 341.940275] audit(1193770427.334:10): type=1503 operation="capable" name="dac_override" pid=5609 profile="/usr/lib/cups/backend/cups-pdf"

Oct 30 11:53:47 dell kernel: [ 341.940285] audit(1193770427.334:11): type=1503 operation="capable" name="dac_read_search" pid=5609 profile="/usr/lib/cups/backend/cups-pdf"

Oct 30 11:53:47 dell kernel: [ 342.013681] audit(1193770427.334:12): type=1503 operation="inode_create" requested_mask="w" denied_mask="w" name="/home/bob/autosave/job_779-My_Excite.pdf" pid=5612 profile="/usr/lib/cups/backend/cups-pdf"

Anyone have any idea what I need to do to get this working. This works if I leave the output directory as 'PDF', and I was able to change the output directory to 'autosave' in Feisty. I reinstalled the PDF printer driver, but this didn't help.

Thanks!

[Martin-Éric Racine (q-funk)]

Till, I never said anything about scripts; I spoke about uses beyond the desktop. CUPS-PDF is meant as a printer. As with any other printer, the point is to make it accessible via CUPS. It is not meant to replace an application's ability to generate a PDF via the Desktop Environment's own services (gtkprint, gnomeprint, etc.). Thus, trying to make CUPS-PDF fit the paradigm of a Print dialog is completely the wrong approach. Besides, it's not an interim solution or a replacement for a unified cross-DE printing system. CUPS-PDF simply addresses a completely different need, in the first place.

[atom (isawdrones)]

I was having this same problem with a non-standard HOME location. For example, my home is /adam .

To me, @{HOME} should work for any home location, but clearly it does not.

[labinnsw (labinnsw)]

I am trying to find the solution to the original problem in here, but I cannot seem to understand it. Could someone please do a step by step summation of the steps that need to be taken to solve the problem.

[Eric Belhaire (ebelhaire)]

I have the same with a cups-pdf fails to generate any file, on an updated Gutsy system (everything was perfect with Feisty).

In /var/log/cups/cups-pdf_log:
Mon Dec 3 07:11:26 2007 [ERROR] failed to set file mode for PDF file (non fatal) (/home/eric/ubuntu/PDF/foo_bs3_bulpaie.pdf)

In /var/log/kern.log:
Dec 3 08:11:25 monbillou kernel: [ 1098.324000] audit(1196665885.930:4): type=1503 operation="capable" name="dac_override" pid=8883 profile="/usr/lib/cups/backend/cups-pdf"
Dec 3 08:11:25 monbillou kernel: [ 1098.324000] audit(1196665885.930:5): type=1503 operation="capable" name="dac_read_search" pid=8883 profile="/usr/lib/cups/backend/cups-pdf"
Dec 3 08:11:26 monbillou kernel: [ 1098.412000] audit(1196665885.930:6): type=1503 operation="inode_create" requested_mask="w" denied_mask="w" name="/home/eric/ubuntu/PDF/foo_bs3_bulpaie.pdf" pid=8886 profile="/usr/lib/cups/backend/cups-pdf"

In /etc/cups/cups-pdf.conf:
Out ${HOME}/PDF
(HOME is /home/eric/ubuntu)

In /etc/apparmor.d/usr.sbin.cupsd
  @{HOME}/PDF/ w,
  @{HOME}/PDF/* w,

It seems that the new system does not accept my configuration, but why ? Is it because home is non standard as it is /home/eric/ubuntu ?

Any idea ?

ericbe

[labinnsw (labinnsw)]

I have found a solution to my problem. Before I give the solution, I would like to briefly describe what my problem was and how it started.

I had a working Feisty and upgraded to Gutsy. After that I could no longer print to PDF. I read and followed the instructions from various posts and nothing changed until last night. I found a post at https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/152537 about an unrelated matter. I tried one of the solutions offered there "sudo aa-complain cupsd" and the problem the problem was immediately fixed.

It may or may not work for you. If it does work I would like to know.

labinnsw

[Till Kamppeter (till-kamppeter)]

AppArmor issue, moving to CUPS ...

[Eric Belhaire (ebelhaire)]

The solution proposed by labinnsw works for me too.
ericbe

[Paolo (paolo-notari)]

the solution proposed by labinnsw didn't work for me

$ sudo apt-get remove --purge apparmor apparmor-utils worked properly in order to reetabilish pdf printing with desired output.

it would be interesting to know when apparmor will have a fix, in order to reinstall it.

[Sean "Diggity" O'Brien (seandiggity)]

I changed the cups-pdf output directory in /etc/cups/cups-pdf.conf:
Out ${HOME}/Desktop

and also in /etc/apparmor.d/usr.sbin.cupsd:
  @{HOME}/Desktop/ w,
  @{HOME}/Desktop/* w,

It didn't work, so I ran:
sudo aa-complain cupsd

...and now the cups-pdf printer saves PDFs to the ~/Desktop folder. Thanks labinnsw for the (temporary?) solution. Does anyone know if setting cupsd to "complain mode" is unwise for any reason? I don't have any expertise on this issue.

Also, when I "Print Test Page" via /usr/bin/system-config-printer (System > Administration > Printing in my Gnome panel menu), it still outputs to /var/spool/cups-pdf/ANONYMOUS as others describe above.

[Martin Pitt (pitti)]

Hi,

Sean Diggity O'Brien [2008-01-01 19:57 -0000]:
> ...and now the cups-pdf printer saves PDFs to the ~/Desktop folder.
> Thanks labinnsw for the (temporary?) solution. Does anyone know if
> setting cupsd to "complain mode" is unwise for any reason? I don't have
> any expertise on this issue.

That'll work of course, but cupsys is a pretty big attack vector for
security vulnerabilities, especially if you export printers to the
local network. If you are in a home network with a trusted local
ethernet, or just use it locally with trusted users on your box, you
can disable it without worrying a lot.

[Chris Conroy (chrisconroy)]

i have my /home directory symlinked to another location due to my partitioning setup. as a result, I had to add another entry into $HOMEDIRS in /etc/apparmor.d/tunables/home in order to let apparmor recognize my symlinked home directory

I imagine users experienced with apparmor already know to do this, but I'm new to Ubuntu and it took me a little while to troubleshoot this bug. perhaps it will be a useful hint to others who google the error and come here.

[Mark Kohler (mkohler)]

I'm seeing the same error everyone else is talking about ("failure to set file mode"), except that setting aa-complain, or even removing apparmor entirely doesn't fix the problem for me. Plus, my home directory isn't in a non-standard place.

I had this working on edgy, but I seem to remember I had to do a bunch of configuration hacking to make it work. I'm wondering if something I did then is causing a problem now. (I'm using an up-to-date gutsy.)

I've bumped up the log level of /etc/cups/cups-pdf.conf, and attached the log file. Can anyone suggest where to look next?

[Helge Stenström (h-stenstrom)]

How do you bump the log level of /etc/cups/cups-pdf.conf?

I have a similar problem. When I'm logged in as my regular user, printing to ~/PDF doesn't work. But as another user it works.

An perhaps important difference is that the first user is at /localhome/username, whereas the other is at /home/username, where /home is mounted using NFS and NIS. The first user comes from /etc/passwd and the second comes from NIS.

Or perhaps not. I just saw in /var/log/cups/cups-pdf_log:
Fri Mar 7 16:45:12 2008 [ERROR] failed to set file mode for PDF file (non fatal) (/localhome/helge/PDF/nios_print_and_fax_curr_SEK_loc_en-SE.pdf)
a number of times.

[Onno Benschop (onno-itmaze)]

Helge, in /etc/cups/cups-pdf.conf look for LogType, the instructions are above it.

[Martin Pitt (pitti)]

Not an AppArmor bug.

[Martin Pitt (pitti)]

cups-pdf itself works as designed, not a bug there either.

[Martin Pitt (pitti)]

If you change configuration files in cups-pdf, then you need to do the corresponding change in cupsys' apparmor profile. While this is slightly inconvenient, we won't change this. cups-pdf is scary enough as it is, so we won't relax the AppArmor proptection further.

Thank you! Martin

[Sean "Diggity" O'Brien (seandiggity)]

This appears to be fixed in the Hardy beta. I changed the cups-pdf output directory in /etc/cups/cups-pdf.conf:
Out ${HOME}/Desktop

...and it worked with no need to do anything else :)

[Martin-Éric Racine (q-funk)]

Sean, can you please paste us the result of the following command?

dpkg -l | grep armor

Thanks!

[Sean "Diggity" O'Brien (seandiggity)]

ii apparmor 2.1+1075-0ubuntu9 User-space parser utility for AppArmor
ii apparmor-utils 2.1+1075-0ubuntu9 Utilities for controlling AppArmor

I just did a fresh install of Hardy on a Thinkpad T30, and it worked.

[Rüdiger Blach (rblach)]

My problem was a non-standard home directory:

Fri Apr 11 17:27:37 2008 [ERROR] failed to set file mode for PDF file (non fatal) (/wihome/wi/blach/PDF/Get_Organized_with_Emacs_Org-mode.pdf)

Chris Conroy's (2008-01-19) solution works for me. Thank you Chris!

I changed in `/etc/apparmor.d/tunables/home'
the line "@{HOMEDIRS}=/home/"
into "@{HOMEDIRS}=/home/ /wihome/*/"
and reloaded it with `/etc/init.d/apparmor reload'.

So I think it is not really a bug,
but an apparmor related configuration task for an administrator.

[LeoRochael (leorochael)]

In my system, a Gutsy, the problem was solved by editing

  /etc/apparmor.d/usr.sbin.cupsd

and changing the entry that read:

/usr/lib/cups/backend/cups-pdf {

to:

/var/lib/cups/backend/cups-pdf {

Since that was the path to the executable which apparmor complained about violations in /var/log/kern.log

Reading /var/log/kern.log is the ticket out of this issue.

[Mark Kohler (mkohler)]

In case someone else is having these symptoms independently of apparmor, the problem on my gutsy system was that there was no /var/tmp, and without that, ghostscript refused to create the PDF file. I have no idea what happened to my /var/tmp, but once I re-created it, cups-pdf worked fine.

[Martin Pitt (pitti)]

LeoRochael [2008-04-22 23:20 -0000]:
> /var/lib/cups/backend/cups-pdf {
>
> Since that was the path to the executable which apparmor complained
> about violations in /var/log/kern.log

What??? The Debian/Ubuntu package does no such thing. The binaries are
shipped and installed into /usr/lib/cups/backend/, where they belong.
Do you use some third-party packages or other customizations?

[Sean "Diggity" O'Brien (seandiggity)]

On my updated Hardy machines, I have to edit two files to get this to work.

I changed the cups-pdf output directory in /etc/cups/cups-pdf.conf:
Out ${HOME}/Desktop

and also in /etc/apparmor.d/usr.sbin.cupsd:
  @{HOME}/Desktop/ w,
  @{HOME}/Desktop/* w,

...I did not need to set cupsd to complain mode as in the past with Gutsy, however. Not sure why I had to edit those two files, since editing only /etc/cups-pdf.conf worked when I posted last month. I'm running the same package versions I did then:

ii apparmor 2.1+1075-0ubuntu9 User-space parser utility for AppArmor
ii apparmor-utils 2.1+1075-0ubuntu9 Utilities for controlling AppArmor

[John Johansen (jjohansen)]

Sean,

would it be possible to attach your log files or a section of them so that I can analyze why it is requiring
  @{HOME}/Desktop/ w,
  @{HOME}/Desktop/* w,

[Sean "Diggity" O'Brien (seandiggity)]

From /var/log/cups/cups-pdf_log:

Wed May 7 14:03:43 2008 [ERROR] failed to set file mode for PDF file (non fatal) (/home/diggity/Desktop/aaa_card.pdf)
Wed May 7 16:27:15 2008 [ERROR] failed to set file mode for PDF file (non fatal) (/home/diggity/Desktop/Microsoft_Word_-_unencumber_ws_08-09.pdf)

I was not able to generate /home/diggity/Desktop/aaa_card.pdf. After editing /etc/apparmor.d/usr.sbin.cupsd, I could generate /home/diggity/Desktop/Microsoft_Word_-_unencumber_ws_08-09.pdf.

For the corresponding jobs, /var/log/cups/access_log reads:

localhost - - [07/May/2008:14:03:43 -0400] "POST / HTTP/1.1" 200 181 Get-Jobs successful-ok
localhost - - [07/May/2008:16:27:15 -0400] "POST / HTTP/1.1" 200 181 Get-Jobs successful-ok

For the corresponding jobs, /var/log/cups/error_log mentions nothing.

For the corresponding jobs, /var/log/cups/page_log reads:

PDF diggity 13 [07/May/2008:14:03:43 -0400] 1 1 - localhost
PDF diggity 14 [07/May/2008:16:27:15 -0400] 1 1 - localhost

There is nothing in /var/log/apparmor. None of the info above seems helpful, so please let me know if I should look elsewhere.

[Martin Pitt (pitti)]

Sean Diggity O'Brien [2008-05-08 5:36 -0000]:
> There is nothing in /var/log/apparmor. None of the info above seems
> helpful, so please let me know if I should look elsewhere.

Unfortunately AppArmor kernel errors do not land there, but in
kern.log. Please try

  grep audit /var/log/kern.log

right after you reproduced the problem. Thanks!

[drink (martin-espinoza)]

I'm having this problem on Gutsy, too. Soon I guess I will be upgrading to Hardy, but it is sad to have to upgrade the OS to fix printing.
My system is saving PDFs to ~/PDF. Or at least it should:

Out ${HOME}/PDF

Haven't messed with the apparmor config at all. In fact AppArmor has NEVER worked on my system:

$ sudo /etc/init.d/apparmor start
FATAL: Error inserting apparmor (/lib/modules/2.6.22-14-generic/ubuntu/security/apparmor/apparmor.ko): Resource temporarily unavailable
$Loading AppArmor module: Failed.

The system was upgraded from dapper to edgy to feisty to gutsy. So it doesn't even register! So, how could it be responsible for this problem? Maybe it isn't?

Sat May 17 14:41:07 2008 [ERROR] failed to set file mode for PDF file (non fatal) (/home/drink/PDF/california_highway_sign_-_Google_Search.pdf)

Of course doing "grep audit /var/log/kern.log" produces no output - because AppArmor doesn't even load here.

This worked in Feisty, magically broke itself in Gutsy, AppArmor is not or at least should not be the problem. What's up?

[pt123 (pt123)]

confirming this in Hardy, changing the PDF folder in the home dir to a Syslink folder, throws the same error.
[ERROR] "failed to set file mode for PDF file "

[mexlinux (mcanedo)]

http://ubuntuforums.org/showthread.php?t=569873

[Tom Cameron (drdabbles)]

My Hardy machine is part of a Windows domain, meaning my home is /home/DOMAIN/user. This throws off AppArmor, and I have to manually add the full path to my ~/PDF directory just to print a PDF. Seems AppArmor is a bit buggy with "non-typical" paths.

[Claus Frein (cfrein)]

Same issue for me using likewise-open to authenticate against Active Directory. The path to $HOME seems not to be used by apparmor for domain-users.

[Bob Blanchard (blabj)]

Had this issue on hardy, found this bug - thought I'd share my solution.

In /etc/apparmor.d/usr.sbin/cupsd , here is my /usr/lib/cups/backend/cups-pdf section:

/usr/lib/cups/backend/cups-pdf {
  #include <abstractions/base>
  #include <abstractions/fonts>
  #include <abstractions/nameservice>
  #include <abstractions/user-tmp>

  capability chown,
  capability fowner,
  capability fsetid,
  capability setgid,
  capability setuid,

  /bin/dash ixr,
  /bin/bash ixr,
  /etc/papersize r,
  /etc/cups/cups-pdf.conf r,
  @{HOME}/PDF/ rw,
  @{HOME}/PDF/* rw,
  /usr/bin/gs ixr,
  /usr/lib/cups/backend/cups-pdf mr,
# /usr/lib/ghostscript/** mr,
  /usr/share/** r,
  /var/log/cups/cups-pdf_log w,
  /var/spool/cups-pdf/** rw,
  /var/tmp/ rw,
  /var/tmp/** rw,
  /var/spool/cups/ rw,
  /var/spool/cups/** rw,
}

NOTE: commented out reference to non-existent /usr/lib/ghostscript, and added /var/tmp and /var/spool/cups.

ALSO - output directory has to have perms at 700.. ie. chmod 700 ~/PDF

[Jay (jerome-avond-free)]

Sorry I haven't got the time to read the rest,

What about changing /etc/apparmor.d/usr.sbin.cups like that :

 @{HOME}/PDF/ rw,
 @{HOME}/PDF/* rw,

by that :

 @{HOME}/ rw,
 @{HOME}/** rw,

Anybody can set up his output as he wants in /etc/cups/cups-pdf.conf

And everything's okay.

[hanasaki (hanasaki-ubuntu)]

2009-08-30 Juanty with all current updates
- out of the box installation
- apparmor : not changed
 @{HOME}/PDF/ rw,
 @{HOME}/PDF/* rw,
- NFS mounted home dir fails to print PDF
/storage/data-01/dist-export

etab =
10.1.1.0/255.255.255.0(rw,sync,wdelay,hide,nocrossmnt,secure,no_root_squash,no_all_squash,no_subtree_check,secure_locks,acl,anonuid=65534,anongid=65534)
~home directories are automounted by autofs from /storage/data-01/dist-export
automount file
* -fstype=nfs,lock,rw,intr,hardrsize=8192,wsize=8192,nosuid,minproto=3 fileserver-01:/storage/data-01/home/export/&

ERROR SHOWN IN SYSLOG
==================
... operation="inode_create" requested_mask="a::" denied_mask="a::" fsuid=1001 name="/home/export/ ...

[pmoreno (mdpmgdb)]

Hi all,

We've configurated CUPS which prints correctly both in local (in /home/pilar/PDF directory) and remote (in /var/spool/cups-pdf/ANONYMOUS).

In local, we can print the pdf file in any directory we indicate (E.g.: /home/pilar/PDF). However, in remote we are just able to print in /var/spool/cups-pdf/ANONYMOUS.

If we change the directory name AnonDirName /var/spool/cups-pdf/ANONYMOUS to AnonDirName /home/pilar/java, we get the following error in the cups-pdf-log file:

[ERROR] failed to set file mode for PDF file (non fatal) (/home/pilar/java/Crear_impresora_virtual_de_PDF___Kript__polis.pdf)

We tried with the command sudo aa-complain cupsd, but the error remains.

Do you know why is this happening? We would really appreciate your help.

Looking forward to hear from you.

Thank's in advance

[pmoreno (mdpmgdb)]

Hi all again,

i solved my problem with: sudo chmod 777 -R /home/pilar/java

thanks

[Tim Golobic (timgolobic)]

I'd like to output to the desktop instead of the cups-pdf folder.

I changed the cups-pdf output directory in /etc/cups/cups-pdf.conf:
Out ${HOME}/Desktop

But now nothing happens. The PDF does not end up on the Desktop not in the cups-pdf folder. The log says successfully created.

This is under a new Snow Leopard install. With the AnonDirName and Spool path settings commented out as the default.

Thanks

Tim

[Christian (c-pradelli)]

If user home is not in default linux path ("/home/...") you need to reconfigure apparmor, previous to Lucid you need to edit:

sudo gedit /etc/apparmor.d/tunables/home

an add your home directories path in:

@{HOMEDIRS}=/home/ /my_homes_path/

In Lucid you can do:

sudo dpkg-reconfigure apparmor

Also in Lucid, if home is in NFS mount, is not necessary any more to export it no_root_squash

[MANGA Willy Ted (manga-willy)]

@christian
"Also in Lucid, if home is in NFS mount, is not necessary any more to export it no_root_squash "

Are you sure about your statement ?
When I read cups-pdf README [1] it is said " Make sure if any of CUPS-PDF's working directories (e.g. output) are located on an NFS mounted volume they are mounted without root_squash! "

1. /usr/share/doc/cups-pdf/README , setting up the PDF queue with CUPS

[Josef Hopfgartner (josef-netzagentur)]

This is what syslog says:
apparmor="DENIED" operation="connect" profile="/usr/lib/cups/backend/cups-pdf" name="/run/samba/winbindd/pipe" pid=15076 comm="cups-pdf" requested_mask="wr" denied_mask="wr" fsuid=0 ouid=0

So, in /etc/apparmor.d/usr.sbin.cupsd a new entry has to be entered:
    /run/samba/winbindd/pipe rw,

[Norbert (nrbrtx)]

Found interesting moment:
  my home folder has two partitions (with AuFS), cups-pdf stopped to work after such migration with messages:
  [ERROR] failed to create user output directory (/home/norbert/PDF)

  Oct 8 22:26:52 localhost kernel: [ 1266.664351] type=1400 audit(1412792812.136:170): apparmor="DENIED" operation="mknod" profile="/usr/lib/cups/backend/cups-pdf" name="/mnt/UHOME_HDD/norbert/PDF/Untitled_Document_1.pdf" pid=7276 comm="gs" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

I got it working again after adding /mnt/UHOME_HDD and /mnt/UHOME_SSD as homes to 'dpkg-reconfigure apparmor'. Hope it help somebody.

[Zenaan Harkness (zenaan)]

For reference, just steamrolled through this same saga, and finally figoured out that Geany and Mousepad each use the same print dialog (gnome?) which provides a "print to file" option, which provides to choose both a save location and the output/save format (PDF, PS, SVG). That might help some who missed the obvious...