Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I am accessing cups through the Mac web interface locally and need to change some settings. I typed in the address (http://127.0.0.1:631) and went to the admin panel (no login required).

I went to change some options in the Server section, I checked the boxes and hit "Change Settings". The page reloaded without the two options checked just as before.

Why won't my system take my config changes, do I need to login somewhere?

P.S.: I tried repairing disk permissions as that seems to be the standard thing to do when a mac isn't working right, but that didn't do it.

share|improve this question
    
Which version of Mac OS X and is your user account an Administrator account? –  Chealion Sep 5 '10 at 3:33
add comment

3 Answers

up vote 3 down vote accepted
+300

For CUPS on Mac OS X you do need to authenticate your user but it's not exactly obvious on how to do this. Once you've authenticated your session (using your login name and password) then the rest of the interface works as expected. It should prompt you for your username and password when you click the "Change Settings" button.

I've also found authentication only works correctly if you're using Safari - it fails in Chrome and Firefox. (Older versions in Tiger and Leopard worked fine with other browsers)

share|improve this answer
    
I have tried using Safari and when I click the "Change Settings" button nothing happens, I'm not prompted for anything. I even tried running Safari.app as root and it didn't work. –  Daisetsu Sep 7 '10 at 19:28
    
@Daisetsu: Use localhost:631 and it works as I said in my answer. 127.0.0.1 doesn't work. (Didn't think it would matter) –  Chealion Sep 7 '10 at 22:03
    
Yup, it was localhost which was the problem. Thanks so much! –  Daisetsu Sep 8 '10 at 16:25
2  
The reason this only works in Safari is because the Set-Cookie is considered malformed (trailing semi-colon, I believe). Different browsers treat this kind of error differently. –  Martijn Pieters Oct 6 '10 at 10:01
    
@Martijn Pieters: Good to know why it doesn't work. –  Chealion Oct 6 '10 at 17:07
add comment

By default, the CUPS admin interface needs 'root' to change anything. By default, OSX leaves the 'root' user disabled. To make changes by way of the CUPS web interface, you need to enable root. Apple has published a procedure for this, the exact steps vary by OS X version:

http://support.apple.com/kb/HT1528?viewlocale=en_US

For 10.6:

  1. From the Apple menu choose System Preferences....
  2. From the View menu choose Accounts.
  3. Click on the lock and authenticate with an administrator account.
  4. Click Login Options....
  5. Click the "Edit..." or "Join..." button at the bottom right.
  6. Click the "Open Directory Utility..." button.
  7. Click the lock in the Directory Utility window.
  8. Enter an administrator account name and password, then click OK.
  9. Choose Enable Root User from the Edit menu.
  10. Enter the root password you wish to use in both the Password and Verify fields, then click OK.

You may have to restart CUPS after performing the above procedure in order for this to do what you want.

share|improve this answer
add comment

From What Password Do I Need to Use in the Web Interface?

MacOS X 10.3.x broke user authentication in the web interface. The following comes from the folks at Apple:

What's happening here is OS X 10.3 (Panther) switched to a form of shadow passwords that cupsd isn't able to read. The getpwent(3) man page discusses the details:

As of Mac OS X 10.3, there are now different per-user behaviours of this function, based on the AuthenticationAuthority value stored for the queried user in DirectoryServices.

If the queried user is still a legacy crypt password user or now has an AuthenticationAuthority value containing ";basic;", these routines will behave in their standard BSD fashion. These functions will "shadow" the password file, e.g. allow only certain programs to have access to the encrypted password. If the process which calls them has an effective uid of 0, the encrypted password will be returned, otherwise, the password field of the returned structure will point to the string '*'.

By default in Mac OS X 10.3 and later all users will have an AuthenticationAuthority will contain the value ";ShadowHash;". These users will have a visible password value of "**". These functions will have no access to the encrypted password whatsoever. Setting or changing an user password must be done entirely through the DirectoryService APIs for this default user.

Two workarounds for now are:

  1. Remove the <Limit GET> / </Limit> lines from /etc/cups/cupsd.conf
  2. Switch back to crypt passwords. This can be done in Netinfo Manager by changing a user's 'AuthenticationAuthority' from ';ShadowHash;' to ';basic;' and using 'openssl passwd' to set the password. The following macosxhints article talks about this:

    http://www.macosxhints.com/article.php?story=2003102523435492

The CUPS repositories (both Darwin's and cups.org's) have been updated to install a pam(8) configuration file that works with these passwords via the pam_securityserver module. This solved the problem in Tiger.

The comments for the above article also contain some pertinent information.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.