10.4 OD Server & 10.5 client – Error 118

Alright so back to work ; I’m still nowhere with this issue, despite Joel’s leads (thanks by the way).

Regarding the automount :

1) The automatic one set for the home directories seems to be correct (permissions and way of mounting).
Reading the leopard QS guide of Corey, I corrected the primary group of my user to join him to staff (20) instead of the one I had setup (not sure if it’s mandatory…).
The rest was in pair with Corey’s guide, so that should be correct, the WGM inspector does not report data I hadn’t encountered before so not sure where else I should look.
2) The two partitions that doesn’t mount are all handled by the client and, outside permissions, what else could I check.
If anyone has ideas on what to look for … you’re highly welcome

Regarding the drives MCX setting :

No go for me as nothing is set (not for user, nor for groups or computers)

However, there are a few things I noticed in the logs (once bound to OD) that I thought I’d post to see what you guys think about it.

On the client side :

/System/Library/CoreServices/coreservicesd[46]	SFLSharePointsEntry::CreateDSRecord: dsCreateRecordAndOpen(Dossier public de Administrateur) returned -14135

Creation of a Share Point entry for the public folder of the user homedir … fair enough but it seems to fail ; I checked via another user and it’s accesible and gets updated with changes

com.apple.KerberosAutoConfig[136]	Kerberos configuration is up to date

That’s good right ! – Means the bind is ok, actually…
Still willing to double check :
– Walk the LDAP structure with dscl : worked fine
– Get the id of “diradmin” : worked but I get this entry (among the usual ones) which seems new : 101(com.apple.sharepoint.group.1)

kextd[10]	/Volumes/*FAILINGPARTITIONNAME*: error reading /usr/standalone/bootcaches.plist

Well, not sure about that one …

mds[21]	((null))(Error) IndexCI in indexShadowFiles:open err: 118, 0.shadowIndexHead
mds[21]	((null))(Error) IndexGeneral in notify_lowspace:low space for device 234881028 (/Volumes/*FAILINGPARTITIONNAME*/.Spotlight-V100/Store-V1/Stores/726ED302-6A5A-4F3E-AD13-5791384047CD)
mds[21]	(Error) Volume: LOW DISK SPACE device:234881028
mds[21]	(Error) DiskStore: Unable to create/find index location

Now, this one is interesting…
First line reports the same error 118 as the terminal gives me when trying to ls /Volumes…
The 2 next lines are complaints about disk space … I don’t get it because the partition is 35Gb total and has 11Gb of free space.
The last line should mean that spotlight can’t create the index on it … since it didn’t mounted properly, sounds sort of logical.
These 4 lines are reported in the log for both failing partitions consecutively.

On the server side :

For system.log :

myservername servermgrd: servermgr_dns: Reloaded named
myservername servermgrd: servermgr_dns: hostname and DNS entries for this server are synchronized
...
myservername mDNSResponder: Update _kerberos._tcp.MYCOMPANY.COM. refused
myservername mDNSResponder: Registration of record _kerberos._tcp.MYCOMPANY.COM. type 33 failed with error -65553
myservername mDNSResponder: Update _kerberos._udp.MYCOMPANY.COM. refused
myservername mDNSResponder: Registration of record _kerberos._udp.MYCOMPANY.COM. type 33 failed with error -65553
myservername mDNSResponder: ERROR: hndlLookupSOA - recursed to root label of _kerberos.myservername. without finding SOA
myservername mDNSResponder: RecordRegistrationCallback: error -65537

I have disabled bonjour on my servers, therefore, should I take these seriously and if yes, what could I do about it ?

For slapd.log :

myservername slapd[87]: <= bdb_equality_candidates: (apple-computers) index_param failed (18)\n
myservername slapd[87]: do_search: invalid dn (automountMapName=auto_master,cn=automountMap, dc=mycompany,dc=com)\n

The first line appears often in my regular logs but I have never bothered about it.
The second one is new and seems to relate to leopard autofs (from what I came accross on the web).

For ApplePasswordServer.Server.log

KERBEROS-LOGIN-CHECK: no principal (afpserver/LKDC:SHA1.36199947ABF8390DFE20415C8AF0C7B61A8636FE@MYCOMPANY.COM)

That one shows up for every service (cifs, ftp, imap, vpn, etc…) and corresponds to the local KDC key of my leopard client machine.
Is there any configuration to do with (or for) that machine LKDC in the directory structure ?

➡ Since we are a tiny SMB ; our major OS revisions upgrade cycle is to first treat my machine (that’s the joy of being the admin right ?), heavily test it, then deploy the OS to 2 more clients and finally throw it in full production.
In this case, due to this leopard hurdle, I had to revert to my tiger partition backup in order to do my job … I guess this error wouldn’t go away if my server was 10.5.2 instead of 10.4.11, right ?

I tried to call Apple Support last week but it seems that they don’t care much about a small mac SMB in Belgium.
I’m sure you guys are getting better support from them in the US but over here they don’t seem to take us very seriously … their advice was to upgrade the server to leopard and the error will magically go away

You guys are my only reliable source for help so thanks already to those who takes the time to help me out.