Where are my server credentials stored?

Solution 1:

Things are way weirder than I thought! The way that I access my three shares is:

1. afp://192.168.1.100/Share1
2. afp://192.168.1.100/Share2
3. smb://192.168.1.100/share3

With all the entries deleted from the keychain and I do a "Connect to server", I am prompted for the server side credentials. If I enter them and do not check "Remember this password in my keychain", then all is well and I can correctly log into any of the shares.

The issue seems to be when I do check "Remember this password in my keychain". From experimenting, the keychain only remembers the credentials per IP address and per protocol. So that there was always only ever 2 different entries in my keychain: one for afp://192.168.1.100 and one for smb://192.168.1.100 and that the keychain would ignore the share name itself for a single protocol/IP pair when retrieving the server credentials.

So the sequence of events seems to be:

1. (no credentials in keychain)
2. Access afp Share1
3. Prompted for credentials for Share1
4. Check "Remember.." and the correct credentials are saved for share1 in my keychain.
5. Access afp Share2
6. The keychain gets excited and says "Hey I've got credentials for that IP address and that protocol - here they are!!!!!" and totally ignores the share name itself.
7. Somehow the system then connects to afp Share2, but with the wrong password.
8. With the wrong credentials applied, I end up with a read only access to the share.

I only noticed this because previously I hadn't saved the password for either of the afp shares. Over the weekend I updated the server and as a part of checking that I could access the shares I finally checked the "remember .. " check box. But I didn't get an error or notice that the second share was read only until today when I was trying to use the system.

I did check the smb share and this was connecting as read/write.

Note that I tried to fix things in my Keychain by renaming the afp share entry in order to disambiguate the two afp shares. However this didn't solve anything. It seems the keychain only cares about protocol/IP pairs