OK, I finally got to the bottom of this. There was no issue with write access to the directories it was down to install issues on CUCM7.
When I patched CUCM7 from 7.1.5 to the latest service release I was overly precautious and popped a disk on all the CUCM servers. I then proceeded to install and reboot the cluster into the new version. All appeared well apart from an issue when I rebooted the servers, each server complained that the HW was unsupported even though it worked prior to the patch. I wasn't sure if I'd hit a new bug with the latest service release or my upgrade had gone wrong, so I logged a TAC case.
It turns out upgrading with a disk pulled is not supported, based on the argument that the disk firmware may be updated during an upgrade. The argument doesn't hang together too well as what happens if you have a disk that dies and you get a new disk replacement that has different firmware on it ... the CUCM still needs to work in this scenario! The following is in the release notes:
"Cisco does not support drive pulling/swapping as a method of fast upgrade reversion, restore, or server recovery. "
The worst point was the only way to get out of this scenario switch back to the old version and then reapply the patch so a painful process. However it was made a lot harder by the fact that:
1) DRS no longer worked as a result of the patching process so I couldn't take a backup which was needed if I wanted to switch versions as I would lose the latest database changes. Here's the error I got in the log files:
"Status: ERROR :---Unable to acquire a Lock against all components. Could be because the lock is owned by some other Thread or an upgrade is currently in progress.drfCliMsg: No backup status available"
2) Switch version itself no longer worked due to the patching process so I couldn't even swicth to the old version. A full cluster rebuild was potentially in order .. aghh! I got the following error message:
“Switch Version is not allowed during Licensing Grace Period.”
I fixed item 1 by running a file system check which is an option that you can run from the CUCM Recovery CD download (http://tools.cisco.com/support/downloads/go/ImageList.x?relVer=7.1%283a%29&mdfid=282421166&sftType=Unified+Communications+Manager+Recovery+Software&optPlat=&nodecount=2&edesignator=null&modelName=Cisco+Unified+Communications+Manager+Version+7.1&treeM...)
I fixed item 2 by switching versions from the CUCM Recovery CD. Once I'd c ompleted these two steps I could restore from backup and then reapply the patch with all disks plugged in!
So, bottom line is I should have read the release notes and I should have trusted the CUCM switch version procedure for my original patch upgrade!
Anyhow, at the end of all this process RTMT syslog viewing and also power supply failure alarms worked ok ... so all that was tied in with the HW not being recognised as valid.
Jed
