1

I am just trying to make the cups page appear on a client machine. I have installed cups via apt-get install cups. I have installed the cups client via apt-get install cups cups-client.

I have edited the cups.conf.d file to allow access to the server:

Restrict Access to the Server
<Location />
##Order allow,deny
##Allow all
</Location>

When I go to the client machine and type localhost:631/admin, I receive The Unable To Connect screen...

Any suggestions on what is going wrong?

1
  • 1) A # at the beginning of a line in a cups configuration file indicates that the line has been commented out and will be ignored. Is that what you intended? 2) What file are you editing? On the client or on the server? /etc/cups/cupsd.conf or something else? 3) Could you please post the full filename and full contents of the file, and specify which computer it's from?
    – user533208
    May 2, 2016 at 13:10

1 Answer 1

0

I recently upgraded from 64-bit XUbuntu 14.04 "Trusty" to the 64-bit XUbuntu 16.04 "Xenial" and then I experienced the same issue.

Here's the command that fixed this for me (run it on the cups server):

sudo mv /etc/systemd/system/multi-user.target.wants/cups.path /etc/systemd/system/multi-user.target.wants/cups.service

...then restart your server computer, or alternatively run this command:

sudo service cupsd restart

...and use your client machine to check if the problem is gone.


  • Now the explanation:

On *Ubuntu systems, there must be a cups.service file working as a symlink (a symbolic link) that points to /lib/systemd/system/cups.path. In other words, the correct should be this:

/etc/systemd/system/multi-user.target.wants/cups.service -> /lib/systemd/system/cups.path

However, it seems that the most recent *Ubuntu builds are coming with a misconfiguration that has this:

/etc/systemd/system/multi-user.target.wants/cups.path -> /lib/systemd/system/cups.path

...which causes the rc.d scripts not to work properly at bootup (system initialization / startup).

Renaming the extension of the symlink file from cups.path to cups.service (and then restarting the computer or the cups daemon) thus fixes the issue.


If the above solution doesn't solve the problem (or if such error is not present in your system), then another possible reason is the HostnameLookups parameter is set to Off argument instead of On. In order to fix it, just run this command on your cups server machine:

sudo sed -i -e 's/HostnameLookups Off/HostnameLookups On/' "/etc/apache2/apache2.conf"

...and then restart your computer. If you wish to force it to restart, run this command:

sudo telinit 6

After rebooting the server, use your client machine to check if the problem is gone.


If after all this the problem is still there, remove the cups init script links from your cups server machine:

sudo update-rc.d cups remove

...and then add the links back with their default settings:

sudo update-rc.d cups defaults

...then restart your server computer:

sudo telinit 6

...and use your client machine to check if the problem is gone.


If after this the service still isn't loading, maybe the symbolic link to cpus.service is missing. In order to fix it, first become superuser (run the command below the shell/terminal emulator):

sudo su

...and then run the supercommand below in order to create the symbolic link and start the service right after:

sudo ln -sf /lib/systemd/system/cups.service /etc/systemd/system/multi-user.target.wants/cups.service ; systemctl enable cups.service

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .