Skip to content

The Eclectic Light Company

Macs, painting, and more
Main navigation
  • Downloads
  • M1 & M2 Macs
  • Mac Problems
  • Mac articles
  • Art
  • Macs
  • Painting
hoakley October 19, 2022 Macs, Technology

Troubleshooting keychains

Keychains have been used in macOS and classic Mac OS for well over twenty years. Although they’ve certainly had their moments, they’re now generally one of the most reliable parts of macOS. This article follows on from my introductory explanation as to what keychains are, and outlines how to tackle their problems.

Password requests

By far the most common problem encountered by users are unexpected or multiple requests for passwords to unlock keychains. Although these have been frequent in the past, they need careful handling as they can be exploited by malicious software to trick the user into surrendering their password for abuse.

Before entering your password into any dialog, check that it’s genuine and not malicious, and provides the following:

  • locked padlock icon, with a superimposed miniature icon for the requesting app;
  • name of the requesting app;
  • name of the item it wants to access;
  • name of the keychain to be unlocked;
  • that it’s asking for the keychain password, not your Apple ID or other password.

The exact layout of these items has changed a little over the years.

keychain

This is from Monterey.

keychaindialog

This is from Sierra.

If any request for access to a keychain or its password doesn’t meet all the above, then don’t enter any text into it, and deny the request immediately: it’s likely to be malicious.

You should also be wary of apps suddenly requesting access that they should already have. For example, Safari is normally given full access to your web and Internet access passwords, so it doesn’t prompt you for individual access. If you start seeing requests from Safari to open your login keychain to give access to passwords that it should already have, suspect that the app has been changed, forcing reset of its access rights, or that the requests are bogus; either way you should suspect a security problem. However, this can sometimes occur genuinely when an app has just been updated, for instance.

There are two normal reasons for repeated requests for authentication to unlock keychains: either the app making the request isn’t trusted to access that keychain or item within it, or the keychain is being locked again after use, something that shouldn’t normally happen for the login keychain. If you’re happy that app should be given access to that keychain, instead of pressing Return to Allow that access, click on Always Allow. Your Mac’s security system will then decide whether to give that app lasting access, so saving further requests.

Locking of keychains is simple to observe in the sidebar of Keychain Access, or in Mints’ Keychain tool.

To change locking behaviour of a keychain, select that keychain in the sidebar of Keychain Access and use the Edit / Change Settings for Keychain menu command to show that keychain’s settings. You can then increase the time before that keychain is locked automatically, or disable locking altogether.

If you have custom keychains that are being accessed repeatedly and resulting in repeated password requests, try copying the items being accessed from those to your login keychain, which should eliminate the need to keep opening that custom keychain. Even when you set a custom keychain to be kept unlocked, before you can access it the first time after each login, you’ll be required to enter its password, as it can’t be unlocked automatically in the way that the login keychain is.

Login password mismatch

By default, your user login and login keychain passwords are identical, enabling macOS to automatically unlock your login keychain whenever you log in as that user. When you change your user password, that should automatically change the password for the login keychain as well, ensuring that unlocking still works automatically. However, sometimes the two passwords become different, usually because you changed the password on the login keychain separately.

This results in login requiring you to enter two passwords instead of one. It can normally be rectified by changing the password for the login keychain to the same as the user login password.

Broken keychains

In the past, Keychain Access has also provided a First Aid feature to check and repair faulty or damaged keychains, but it no longer does. Manually reconstructing a keychain or building a fresh one, for instance after resetting the login keychain and wiping its contents, is lengthy and tedious. It’s generally better to migrate or restore from a backup or copy, which isn’t an easy choice either.

Whatever you do, if you’re going to attempt any form of surgery or replacement of a keychain, when working with the login keychain it’s essential to disable Keychain in iCloud first, otherwise changes made in that keychain could be synced across all your other Macs and devices. Sadly, it’s a not uncommon mistake to damage a shared keychain when trying to fix local problems, and that’s even tougher to put right.

Apple Support can be helpful with keychain problems, and can talk you through the steps required to get your Mac’s keychains working again.

Expired certificates

When running older versions of macOS, security certificates provided in system keychains can fall out of date, and then cause all sorts of problems accessing websites and services. If you can locate an updated certificate, install that in the System keychain in /Library/Keychains and those problems should vanish.

Passkeys

Introduced in Safari 16 and most fully in Ventura, there isn’t much to check in a Passkey. Both Safari’s Passwords in Preferences and the Passwords pane report that a Passkey has been set for individual accounts, and offer to send them to another Mac or device by AirDrop if you want. Keychain Access doesn’t yet distinguish Passkeys from other keychain contents, and you shouldn’t try meddling with them.

Share this:

  • Twitter
  • Facebook
  • Reddit
  • Pinterest
  • Email
  • Print

Like this:

Like Loading...

Related

Posted in Macs, Technology and tagged iCloud, keychain, Keychain Access, login, Mints, Passkeys, password, security. Bookmark the permalink.

34Comments

Add yours
  1. 1
    hhanche on October 19, 2022 at 2:37 pm
    Reply

    This is unrelated to the problems mentioned in the article, but I can’t resist bringing it up, just in case you or other readers of your blog have seen it:

    I have several problems with Keychain Access:

    The name of the iCloud keychain is displayed as com~apple~CloudDocs. When I select it, it appears to be empty.

    However, if I enter a search string, all keychain entries show up in the list, including from iCloud keychain (still listed as coming from com~apple~CloudDocs). It doesn’t matter what search string I enter: No filtering takes place, so it’s useless for search, but at least it lets me see the items in the iCloud keychain. Fortunately, I can change the sort order by clicking on column headers, which is of some help in finding what I am looking for.

    This symptom shows up on both my laptops, both a private one and a work one. They have been set up independently, except for both being logged in to the same iCloud account. So most likely, that is where the problem lies.

    Apart from these issues, I have no other keychain related problems that I know of.

    Weird, or what?

    LikeLiked by 1 person

    • 2
      hoakley on October 19, 2022 at 7:36 pm
      Reply

      Thank you. That’s very relevant, although I’d avoid messing with a keychain shared in iCloud, for fear of imminent disaster.
      Presumably you have tried shutting all connecting to that iCloud account down, and bringing them back up one by one, allowing each to sync fully before starting up the next one?
      Howard.

      LikeLike

  2. 3
    Mike on October 20, 2022 at 10:36 am
    Reply

    Another “tell” for a genuine keychain prompt is, I am fairly sure, that tabbing to another app (say Finder) will show Finder in the menu bar as you would expect, and then clicking back into the genuine keychain dialog will not change the app name shown. I believe (but can’t be absolutely sure) that a malicious dialog will bring itself to the foreground and the app name will change. I’d be interested if anyone knows otherwise that this is not a good criterion.

    LikeLiked by 1 person

    • 4
      hoakley on October 20, 2022 at 12:16 pm
      Reply

      Thank you. I don’t know whether that would be hard to simulate in malware. It also isn’t listed by Apple, perhaps because it’s a bit subtle.
      Howard.

      LikeLike

  3. 5
    Theorist on October 21, 2022 at 5:00 am
    Reply

    I use Keychain to access most of my online sites, but also always store all my password-login name combinations in a file on my computer’s encrypted main drive. This is necessary, because occasionally Keychain will fail, and I’ll need to lookup the password and enter it manually.

    What’s the workaround when Passkey fails?

    LikeLiked by 1 person

    • 6
      hoakley on October 21, 2022 at 6:03 am
      Reply

      What do you mean by keychain failing? If your login keychain “fails”, then you can’t log into your Mac, so you can’t access that file on your Mac anyway.
      I haven’t heard of a user suffering login keychain failure for many years now. As with all important files, you then rely on your backups, and that’s no different for passwords or passkeys. This is made rather easier, of course, when you share your keychain in iCloud, when you shouldn’t even need to resort to a backup, as once your Mac has connected to your iCloud account, all your passwords and passkeys there are accessible.
      So I’m not sure what the problem is.
      Howard.

      LikeLike

      • 7
        Theorist on October 21, 2022 at 6:41 am
        Reply

        I was referring to using Keychain to login to online sites, not to log into my Mac. I.e., I’m using Keychain as described by Apple support:

        “Keychain Access is a macOS app that stores your passwords and account information, and reduces the number of passwords you have to remember and manage. When you access a website, email account, network server, or other password-protected item, you may be given the option to remember or save the password. If you choose to save the password, it’s saved in your keychain so you don’t have to remember or type your password every time.”

        So when I say it fails, it means that I can no longer login to the website using Keychain (even though Keychain had been working on that site previously) . IIRC, the issue is the website stops recognizing the password provided by Keychain. The workaround is to go into my password file, look up the password, and enter it manually. That does work, indicating the issue isn’t that the password changed. The next step is to again tell Keychain to save the password I’ve entered, after which I will again be able to use Keychain to login to that website.

        LikeLiked by 1 person

        • 8
          hoakley on October 21, 2022 at 6:54 am

          Thank you. That’s the same keychain.
          What you’re describing is an uncommon corruption of passwords, that occurs because they can be edited and changed. That’s inherent in the way that passwords work.
          Passkeys don’t work like that. You can’t change either the public or private key, but you can replace them with another key pair should you wish to change that passkey. Your Mac doesn’t send anyone the private key, but the server challenges it to perform the authentication. So that mechanism of password failure doesn’t exist.
          Howard.

          LikeLike

      • 9
        hhanche on October 21, 2022 at 6:28 pm
        Reply

        I’m afraid I haven’t done anything as rigorous as that. I have tried logging out of icloud and then back in, though, in order to deal with iCloud Drive synchronisation issues. That caused the machine to spend something like 20 hours resynchronising iCloud drive – an experience I don’t feel like repeating! So for now I just let things slide. iCloud keychain seems to work perfectly fine, it’s just Keychain Access (the app) that is misbehaving.

        LikeLiked by 1 person

  4. 10
    Theorist on October 21, 2022 at 6:44 am
    Reply

    And I should add this isn’t a general failure, it’s a glitch that occasionally happens with individual website logins.

    Thus my question remains: What happens if I have a similar glitch with Passkeys? With Keychain, there’s an easy fix: lookup the pwd and enter it manually. But with Passkeys there is no pwd, so what does one do?

    LikeLiked by 1 person

    • 11
      hhanche on October 21, 2022 at 6:45 pm
      Reply

      If your passkeys are lost or corrupted, you’re screwed, I’m afraid. For that reason, I would rather not use a passkey as the only way to access an account if it is important to me. If the site allows more than one way to get in, you should enable at least one other method, such as a TOTP (time based one time password) that you can store in an app such as Google Authenticator, Authy or (my favourite) OTP Auth.. Those often come with a set of fallback codes that you can print out and stick in a safe place as a method of last resort to get access.

      Just remember that when you use one of these alternate methods of logging in, you don’t enjoy the phishing protection that passcodes provide, so be extra vigilant when using them.

      LikeLiked by 1 person

      • 12
        Theorist on October 21, 2022 at 7:24 pm
        Reply

        Yeah, that’s what I was concerned about. It seems there is something qualitatively different between Keychain and Passkeys that could lead to a significant potential inconvenience with the latter.

        While Howard said that Passkeys don’t have the specific failure mode I experienced with Keychain surely, like any technology, they must have others. So let’s suppose you’ve used both Passkeys and Keychain for a while until you are comfortable Passkeys works. You then disable password access to your account, and use Passkeys only (which is the only way it makes sense to use Passkeys; if you leave password access, it defeats the purpose). But then Passkeys breaks.

        Unless you do the fancy stuff you’re describing, your only recourse is to contact the webmaster, explain the situation, and ask them to reopen password access. That’s far less convenient than the fix when Keychain breaks, which is to simply keep your password stored in a separate document on your computer, and look it up and enter it manually.

        LikeLiked by 1 person

        • 13
          hoakley on October 21, 2022 at 7:35 pm

          I have an article coming in the morning that explains more. Passkeys, like passwords and certificates, are stored in keychains, and don’t have any existence outside them.
          You’re very welcome to continue using passwords as long as you’re able to, but that’s your risk. Meanwhile the rest of us will move forward to better security and freedom from 2FA at last.
          Howard.

          LikeLike

      • 14
        hoakley on October 21, 2022 at 7:28 pm
        Reply

        I’m sorry: that’s misleading.
        I have an article coming in the morning which explains passkeys in more detail, and the safeguards provided. Advising people to enable an insecure alternative method of accessing their online accounts and services isn’t good advice. The whole point of passkeys is to avoid putting people at risk.
        Howard.

        LikeLike

  5. 15
    EcleX on October 23, 2022 at 11:07 am
    Reply

    Sometimes Keychain requests password twice or more in a row using Safari on macOS 12.6 (21G115) Monterey on Intel x86 Mac. Examples:

    – Safari wants to sign using key “privateKey” in your keychain – To allow this enter the “login” keychain password.

    – Keychain Access wants to use the “Certificate” keychain – Please enter the keychain password.

    – Enter the password for “….p12” password for…

    – neagent wants to use your confidential information stored in… in your keychain.

    – neagent wants to access key… in your keychain.

    I wonder if that is normal and if there is a fix for that. Thanks.

    LikeLiked by 1 person

    • 16
      hoakley on October 23, 2022 at 11:19 am
      Reply

      No, that’s not normal at all.
      The first, asking for the login keychain password, shouldn’t happen as Safari should be a trusted app and be able to open that automatically. That suggests that you have a misconfiguration. If you click on Always Allow, then Safari should be given the right to access that without prompting each time.
      The second refers to a custom keychain named “Certificate”. I don’t know why you have created that, but if you need to access contents from it, you’ll either have to manually approve its opening after each startup, as I have explained, or you can copy any items from there to your login keychain, so they’ll be automatically available when that’s opened.
      The other messages aren’t complete, and you don’t include which keychain is being specified, so I’m afraid that I can’t comment further on those.
      Howard.

      LikeLike

      • 17
        EcleX on October 23, 2022 at 4:53 pm
        Reply

        Thanks. I forgot to say that, in all cases, the issue arises when I try to digitally sign a document using Safari. Such signature requires a digital certificate, as the one that uses Adobe Acrobat DC Pro in “Tools > Certificates > Digitally Sign”. Clicking “Always Allow” does not fix it.

        LikeLiked by 1 person

        • 18
          hoakley on October 23, 2022 at 10:03 pm

          Ah – that may well explain the problem. Because Safari doesn’t have special rights in that presumably private keychain owned by Acrobat Pro, it won’t be given those rights by the security system, so has to get the password to unlock that keychain every time. This demonstrates the value of saving certificates to the login keychain, where they are more accessible.
          I suggest a bug report to Adobe would be worthwhile.
          Howard.

          LikeLike

        • 19
          EcleX on October 24, 2022 at 10:26 am

          Thanks. The certificate is issued by an institution and is stored in Apple Keychain. It is used for instance to digitally sign when applying for research grants. Such certificate does not belong to Acrobat. Acrobat DC Pro and Acrobat Reader simply allow to sign with such certificate. For instance, the ones that Adobe show in the two figure examples at:

          Certificate-based signatures
          https://helpx.adobe.com/acrobat/using/certificate-based-signatures.html

          All permissions are granted, but somehow Safari asks twice or more in a row to allow access to such certificate stored in Keychain access. As said, clicking “Always Allow” does not fix it.

          Many users have such issue, as found searching Google for
          Keychain requests password TWICE or MORE

          LikeLiked by 1 person

        • 20
          hoakley on October 24, 2022 at 11:08 am

          According to the message you quoted, that certificate isn’t installed in your login keychain, therefore you’ll ordinarily have to provide the password for that keychain in order to unlock it. It may also be that that keychain is set to lock itself again, and that Safari isn’t given access to it.
          What does Keychain Access say about the keychain it’s stored in? Is it set to lock that keychain automatically, for instance?
          Howard.

          LikeLike

        • 21
          EcleX on October 24, 2022 at 3:26 pm

          The digital certificate is in “Keychain Access > login > Certificates”.

          Double-clicking it shows “Access Control” with “Allow all applications to access this item” and “Access to this item is not restricted”.

          I do not see any option to lock or unlock it. The “File > Lock Keychain ‘login’ (Command L)” is gray dimmed and not selected.

          LikeLiked by 1 person

        • 22
          hoakley on October 24, 2022 at 9:02 pm

          So the certificate is in your login keychain. Can Acrobat use the certificate without requiring you to authenticate?
          Howard.

          LikeLike

      • 23
        EcleX on October 25, 2022 at 8:46 am
        Reply

        After opening a PDF file and “Adobe Acrobat DC Pro > Tools > Certificates > Digitally Sign”, such application shows:

        Using your mouse, click and drag to draw the area where you would like the signature to appear. Once you finish dragging out the desired area, you will be taken to the next step of the signing process.

        After doing it, it shows:

        Adobe Acrobat wants to access key “privateKey”
        in your keychain.
        To allow this, enter the “login” keychain password.

        Typing the Mac admin password and Allow generates the digitally signed PDF, as expected. So all fine there. Therefore, Acrobat asks for the password once, as expected.

        The problem arises on some web sites using Safari, where such password is requested two or more times in a row to digitally sign documents.

        LikeLiked by 1 person

        • 24
          hoakley on October 25, 2022 at 8:59 am

          Well, the first thing you should do is instead of clicking on Allow in Acrobat, you should use Always Allow instead.
          When you click on Allow, macOS security simply lets that app access that item in the login keychain once. Every time you want to access it again, you’ll be prompted again to do so.
          When you click on Always Allow, there will be a security evaluation performed. If the security system considers it acceptable, it should then add Acrobat to the list of apps allowed to access that item without further prompting. It might not, of course, but that might prove a start in reducing the number of times you have to authenticate to access that certificate.
          Howard.

          LikeLike

        • 25
          EcleX on October 25, 2022 at 9:16 pm

          Thanks. The problem of requiring the Keychain Access password twice or more in a row is not when using Acrobat to digitally sign using certificate, but when using Safari to digitally sign using such certificate. Clicking Always Allow does not fix it either. I indicated Acrobat just as an example where such digital certificates are used.

          LikeLiked by 1 person

        • 26
          hoakley on October 25, 2022 at 9:19 pm

          So what you’re saying is that, when working with these certificates, Acrobat doesn’t result in prompts for passwords, but Safari does?
          Howard

          LikeLike

        • 27
          EcleX on October 26, 2022 at 9:33 am

          There is a single personal certificate which is used to identify me when asking for research grants, etc.

          Acrobat uses it to sign PDF documents (example with two figures in the Adobe link above).

          Safari also uses it to digitally sign documents in a web server. The problem only arises in such situation. Typically, Safari asks for password, I enter it, and then asks again a second time. Then goes on to sign. Sometimes it asks for password more than twice in a row.

          As said, many people are experiencing this issue, as found by Google.

          LikeLiked by 1 person

        • 28
          hoakley on October 26, 2022 at 11:12 am

          OK, thanks, here’s what I think is happening and why.
          When you use that certificate in Acrobat, it’s entitled to access it, and it’s stored in an unlocked keychain, so you don’t see any dialogs.
          When you use that certificate in Safari, the situation is different because of Safari’s security. First, Safari doesn’t have access to your login keychain, so you’re prompted to give that first. Then it doesn’t have any access rights to that certificate, so you’re prompted for that too.
          I think Safari does this deliberately, as giving it access to the login keychain would be a security risk, because it would make it easy for an exploit to access other things in the login keychain. Its passwords aren’t stored in the login keychain, but separately, for that purpose. It’s also not configured to have any entitlement to access that specific certificate, so you’re prompted to give that. When macOS security is asked to allow access, it therefore only allows that once, and won’t permit access again without going through the same prompts.
          To confirm those, you’ll need to raise this with the Safari engineers, but I think that’s the reasoning behind its behaviour.
          Howard.

          LikeLike

        • 29
          EcleX on October 26, 2022 at 9:21 pm

          Thanks. Both Acrobat and Safari ask for the Keychain Access (Mac log admin) password once. The problem is that Safari sometimes (not always) asks twice or more times in a row for the same password. So, you enter the password once, it is accepted and immediately it asks again for the very same password. And sometimes, it asks even more times than twice in a row.

          LikeLiked by 1 person

        • 30
          hoakley on October 26, 2022 at 10:06 pm

          OK, now I’m confused. I earlier asked you: “So what you’re saying is that, when working with these certificates, Acrobat doesn’t result in prompts for passwords, but Safari does?”
          You responded: “Safari also uses it to digitally sign documents in a web server. The problem only arises in such situation.”
          Now you say that Acrobat does ask for your login keychain password. But I’ve just tried to explain why I think Safari is asking for it twice.
          Have you raised this in Feedback to Apple? Or tried to contact Safari/WebKit engineers?
          I think this is expected behaviour, as I’ve tried to explain: Safari needs to access the login keychain, and within that to access a certificate to which it normally wouldn’t be entitled. Isn’t that what the text in the dialogs says?
          Howard.

          LikeLike

  6. 31
    EcleX on October 30, 2022 at 2:15 pm
    Reply

    Both Acrobat and Safari ask for the Mac admin password to use the Keychain Access certificate. Acrobat asks once. Safari asks once, and then asks again one or more times more in a row, as previously indicated.

    I have reported that to both Adobe and Apple but they do not know why this issue arises. As indicated above, searching the Internet with Google finds many reports of this issue.

    LikeLiked by 1 person

    • 32
      hoakley on October 30, 2022 at 3:08 pm
      Reply

      I could have sworn I tried to explain what I think is going on here. But if Apple really doesn’t know what is happening, then I despair.
      Howard.

      LikeLike

  7. 33
    Nils on November 11, 2022 at 5:50 am
    Reply

    Does anybody have an idea how to transfer the keychains to another Mac nowadays? Even if I copy the files with Terminal in Recovery Mode into an user account, it will rename the login keychain and creates a new one when I log in to the account. Furthermore, the account won’t use the transferred local items, which are stored in the folder named by the HWID of the Mac. In this folder, the database file just gets smaller, so it seems macOS has removed some data. 

    LikeLiked by 1 person

    • 34
      hoakley on November 11, 2022 at 9:10 am
      Reply

      The simplest ways are to sync with Keychain in iCloud, although you’ll then need to manually transfer any custom certificates, or to migrate from a backup or copy. Simply copying keychains will do that – provide a copy, and not the login keychain, so you’ll then have to manually copy and paste individual items from the copied keychain into the login one.
      Howard.

      LikeLike

Leave a Reply Cancel reply

Fill in your details below or click an icon to log in:

Gravatar
WordPress.com Logo

You are commenting using your WordPress.com account. ( Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. ( Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. ( Log Out /  Change )

Cancel

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Quick Links

  • Downloads
  • Mac Troubleshooting Summary
  • M1 & M2 Macs
  • Mac problem-solving
  • Painting topics
  • Painting
  • Long Reads

Search

Monthly archives

  • February 2023 (16)
  • January 2023 (74)
  • December 2022 (74)
  • November 2022 (72)
  • October 2022 (76)
  • September 2022 (72)
  • August 2022 (75)
  • July 2022 (76)
  • June 2022 (73)
  • May 2022 (76)
  • April 2022 (71)
  • March 2022 (77)
  • February 2022 (68)
  • January 2022 (77)
  • December 2021 (75)
  • November 2021 (72)
  • October 2021 (75)
  • September 2021 (76)
  • August 2021 (75)
  • July 2021 (75)
  • June 2021 (71)
  • May 2021 (80)
  • April 2021 (79)
  • March 2021 (77)
  • February 2021 (75)
  • January 2021 (75)
  • December 2020 (77)
  • November 2020 (84)
  • October 2020 (81)
  • September 2020 (79)
  • August 2020 (103)
  • July 2020 (81)
  • June 2020 (78)
  • May 2020 (78)
  • April 2020 (81)
  • March 2020 (86)
  • February 2020 (77)
  • January 2020 (86)
  • December 2019 (82)
  • November 2019 (74)
  • October 2019 (89)
  • September 2019 (80)
  • August 2019 (91)
  • July 2019 (95)
  • June 2019 (88)
  • May 2019 (91)
  • April 2019 (79)
  • March 2019 (78)
  • February 2019 (71)
  • January 2019 (69)
  • December 2018 (79)
  • November 2018 (71)
  • October 2018 (78)
  • September 2018 (76)
  • August 2018 (78)
  • July 2018 (76)
  • June 2018 (77)
  • May 2018 (71)
  • April 2018 (67)
  • March 2018 (73)
  • February 2018 (67)
  • January 2018 (83)
  • December 2017 (94)
  • November 2017 (73)
  • October 2017 (86)
  • September 2017 (92)
  • August 2017 (69)
  • July 2017 (81)
  • June 2017 (76)
  • May 2017 (90)
  • April 2017 (76)
  • March 2017 (79)
  • February 2017 (65)
  • January 2017 (76)
  • December 2016 (75)
  • November 2016 (68)
  • October 2016 (76)
  • September 2016 (78)
  • August 2016 (70)
  • July 2016 (74)
  • June 2016 (66)
  • May 2016 (71)
  • April 2016 (67)
  • March 2016 (71)
  • February 2016 (68)
  • January 2016 (90)
  • December 2015 (96)
  • November 2015 (103)
  • October 2015 (119)
  • September 2015 (115)
  • August 2015 (117)
  • July 2015 (117)
  • June 2015 (105)
  • May 2015 (111)
  • April 2015 (119)
  • March 2015 (69)
  • February 2015 (54)
  • January 2015 (39)

Tags

APFS Apple AppleScript Apple silicon backup Big Sur Blake bug Catalina Consolation Console diagnosis Disk Utility Doré El Capitan extended attributes Finder firmware Gatekeeper Gérôme HFS+ High Sierra history of painting iCloud Impressionism iOS landscape LockRattler log logs M1 Mac Mac history macOS macOS 10.12 macOS 10.13 macOS 10.14 macOS 10.15 macOS 11 macOS 12 macOS 13 malware Mojave Monet Monterey Moreau MRT myth narrative OS X Ovid painting Pissarro Poussin privacy realism Renoir riddle Rubens Sargent scripting security Sierra SilentKnight SSD Swift symbolism Time Machine Turner update upgrade Ventura xattr Xcode XProtect

Statistics

  • 13,809,258 hits
Blog at WordPress.com.
Footer navigation
  • About & Contact
  • Macs
  • Painting
  • Language
  • Tech
  • Life
  • General
  • Downloads
  • Mac problem-solving
  • Extended attributes (xattrs)
  • Painting topics
  • Hieronymus Bosch
  • English language
  • LockRattler: 10.12 Sierra
  • LockRattler: 10.13 High Sierra
  • LockRattler: 10.11 El Capitan
  • Updates: El Capitan
  • Updates: Sierra, High Sierra, Mojave, Catalina, Big Sur
  • LockRattler: 10.14 Mojave
  • SilentKnight, silnite, LockRattler, SystHist & Scrub
  • DelightEd & Podofyllin
  • xattred, Metamer, Sandstrip & xattr tools
  • 32-bitCheck & ArchiChect
  • T2M2, Ulbow, Consolation and log utilities
  • Cirrus & Bailiff
  • Taccy, Signet, Precize, Alifix, UTIutility, Sparsity, alisma
  • Revisionist & DeepTools
  • Text Utilities: Nalaprop, Dystextia and others
  • PDF
  • Keychains & Permissions
  • LockRattler: 10.15 Catalina
  • Updates
  • Spundle, Cormorant, Stibium, Dintch, Fintch and cintch
  • Long Reads
  • Mac Troubleshooting Summary
  • LockRattler: 11.0 Big Sur
  • M1 & M2 Macs
  • Mints: a multifunction utility
  • LockRattler: 12.x Monterey
  • VisualLookUpTest
  • Virtualisation on Apple silicon
  • LockRattler: 13.x Ventura
Secondary navigation
  • Search

Post navigation

Sunrise on Impressionism: 13 Eugène Boudin
Painted Stories in Britain 8: Shakespeare

Begin typing your search above and press return to search. Press Esc to cancel.

  • Follow Following
    • The Eclectic Light Company
    • Join 3,137 other followers
    • Already have a WordPress.com account? Log in now.
    • The Eclectic Light Company
    • Customize
    • Follow Following
    • Sign up
    • Log in
    • Copy shortlink
    • Report this content
    • View post in Reader
    • Manage subscriptions
    • Collapse this bar
 

Loading Comments...
 

    %d bloggers like this: