Public bug reported:
I needed to make space on / to upgrade my ubuntu, and since /usr/share
is huge (4GB in my case), decided to clone this on /home/share and let
/usr/share -> /home/share.
I then found cups failed to work, there were messages such as
Unable to open "/usr/share/cups/mime": Permission denied
in /var/log/cups/error_log, which eventually gave me the hint what was going on
here.
Also, looking at properties of a printer, the "print test page" button was
greyed out, I could not print a test page. This turned out the easiest way for
me to debug this problem (at least graphically). After the fixes (see below)
and "service cups restart" I would
see the "print test page" button again.
To differentiate between a symlink and other-filesystem as the root
cause, I decided to experiment:
1) I kept /usr/share.d and did /usr/share -> /usr/share.d
This failed, so this pointed to the fact that it's a symlink that was not
allowed by CUPS, since /usr/share.d was on /
but then it surprised me:
2) I kept /usr/share but now /usr/share/cups -> /usr/share/cups.d
worked, despite that it was a symlink.
3) Of course, i confirmed that /usr/share/cups -> /home/cups.d
indeed failed. So,other filesystem is always a fail.
I'm left with this weird puzzle, why CUPS doesn't quite allow a simple symlink
1) or even 3) It seems this is against the unix
philosphy and certainly burnt me and caused me a good fraction of a day of work.
This could very well be a problem on apple's as well, but I have no easy
access to one to test this.
** Affects: cups (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1215733
Title:
cups config files cannot deal with symlinks and/or other filesystems
Status in “cups” package in Ubuntu:
New
Bug description:
I needed to make space on / to upgrade my ubuntu, and since /usr/share
is huge (4GB in my case), decided to clone this on /home/share and let
/usr/share -> /home/share.
I then found cups failed to work, there were messages such as
Unable to open "/usr/share/cups/mime": Permission denied
in /var/log/cups/error_log, which eventually gave me the hint what was going
on here.
Also, looking at properties of a printer, the "print test page" button was
greyed out, I could not print a test page. This turned out the easiest way for
me to debug this problem (at least graphically). After the fixes (see below)
and "service cups restart" I would
see the "print test page" button again.
To differentiate between a symlink and other-filesystem as the root
cause, I decided to experiment:
1) I kept /usr/share.d and did /usr/share -> /usr/share.d
This failed, so this pointed to the fact that it's a symlink that was not
allowed by CUPS, since /usr/share.d was on /
but then it surprised me:
2) I kept /usr/share but now /usr/share/cups -> /usr/share/cups.d
worked, despite that it was a symlink.
3) Of course, i confirmed that /usr/share/cups -> /home/cups.d
indeed failed. So,other filesystem is always a fail.
I'm left with this weird puzzle, why CUPS doesn't quite allow a simple
symlink 1) or even 3) It seems this is against the unix
philosphy and certainly burnt me and caused me a good fraction of a day of
work.
This could very well be a problem on apple's as well, but I have no
easy access to one to test this.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1215733/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
