Hi all,
I'm at a loss for what exactly is going on. Our faculty home directories reside on a file server that serves our mac users via AFP. I applied the March 2012 Scheduled Maintenance for OES2 SP3 a few days ago, and everything applied fine, seemingly no issues. However, the next day, it became readily apparent that AFP was not happy at all. It will run until a client tries to connect, at which point the volume mounts, but the AFP daemon then crashes around 5-10 seconds later.
The AFP debug logs stop right there,no final errors, just the normal VerifyObject errors that afp blasts out as it searches from context to context for a matching username. At this same time, ncpsrv.log spits this out at me between an afp restart and a crash.
ncpserv.log
[! 2012-06-18 07:20:17] cross_proto_handler cifsup:msgverb=6 msglen=42 msgver=1
[! 2012-06-18 07:20:30] MapGUIDToRemoteDN: could not Map GUID To DN remote search failed
[! 2012-06-18 07:20:30] MapGUIDToRemoteDN: could not Map GUID To DN remote search failed
[! 2012-06-18 07:20:30] MapGUIDToRemoteDN: could not Map GUID To DN remote search failed
[! 2012-06-18 07:20:30] MapGUIDToRemoteDN: could not Map GUID To DN remote search failed
[! 2012-06-18 07:20:30] MapGUIDToRemoteDN: could not Map GUID To DN remote search failed
[! 2012-06-18 07:20:31] MapGUIDToRemoteDN: could not Map GUID To DN remote search failed
I did find reference to some AFP related errors in the March Maintenance patch in this TID - Support | OES2SP3 - Degraded backup performance and segfaults in AFP and Adminusd and problems managing User quota's since applying the March 2012 Scheduled Maintenance update . It asks that you open an SR to get an FTF. We've got no allotment of SRs, so I'm not sure what to do next. Can I somehow roll back that maintenance patch? Anyone else seen this behavior?
Thanks
Pete