Asset ID: |
1-72-1497162.1 |
Update Date: | 2014-12-07 |
Keywords: | |
Solution Type
Problem Resolution Sure
Solution
1497162.1
:
Pillar Axiom: Clients cannot connect on the NAS, KerberosClockSkewDetected messages
Related Items |
- Pillar Axiom 300 Storage System
- Pillar Axiom 600 Storage System
- Pillar Axiom 500 Storage System
|
Related Categories |
- PLA-Support>Sun Systems>DISK>Axiom>SN-DK: Ax600
|
Explains how to solve problems linked to wrond NTP settings
In this Document
Created from <SR 3-6293496661>
Applies to:
Pillar Axiom 300 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Pillar Axiom 500 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Pillar Axiom 600 Storage System - Version Not Applicable to Not Applicable [Release N/A]
Information in this document applies to any platform.
Symptoms
Client cannot access the NAS
Cause
If the time is not synchronised properly between the clients and the NAS Slammer, time skew messages will appear in the console.
It can be the client that do not have the right system date or the NAS Slammer that is desynchronised. If the time difference is 5min or more, client cannot access the shares because of the Kerebos security in the CIFS protocol.
In most cases no client can access the NAS shares and that is typical of wrong NTP settings.
Most probably a Windows Domain Controller NTP service is being used to synchronise the Axiom.
Microsoft does not implement all the functionalities of the NTP protocol and therefore it is not compatible with the Axiom that relies on the standard NTP protocol. The Axiom will then lose the time synchronisation until the difference between the Domain Controller and the Axiom is greater than 5 minutes, then the CIFS access is denied to Windows clients
Solution
Quickfix:
If you remove the NTP settings and set up the time on the pilot manually, as long as the time difference between the Axiom and your Domain Controller is less than 5 minutes, Windows clients will be able to connect.
You can alternatively open an SR to engage a Support Engineer that will be able to reset the NTP services and perform more advanced investigations.
- Download the Get_NodeTime.exe in http://intranet.trans.corp/cust_svc/CSPackages/TOOLS_R4/GetNodes_Time_R4/ and provide the tool to the customer.
If the customer does not use windows, you will have to manually upload /home/psg/scripts/axiom/pilot/node_sys-time/node_sys-time.sh on the pilot via an scp session
- Activate SSH on the pilot Document: 1431693.1
- Run the script GetNodes_Time_4.0.exe set in order to force the ntp client on the Slammers to restart
Permanent fix:
The NTP server MUST be a standard NTP unix based daemon without authentication. The standard Linux or Solaris ntpd works very well to synchronise the Axiom.
It is possible to use the NTP services from a router as long as they do not require any type of authentication. Most cisco routers, for example, require an MD5 authentication that is not supported by the Axiom.
For details about how to check than NTP works, you can read: https://stbeehive.oracle.com/content/dav/st/systsc_disk_axiom_ws/Documents/Internal_Technical_Procedures/time_skew.doc
In sum up, once the ntp details on the Axiom GUI have been changed:use GetNodes_Time_4.0.exe without parameters. It will create a report in which you will find the output of ntpq.
The output must show a star "*" in front of one of the defined NTP server on the pilot if it is the case, the NTP server has a trusted status and it is properly configured.
remote refid st t when poll reach delay offset jitter
==============================================================================
pilot1 .STEP. 16 u 12 64 0 0.000 0.000 4000.00
*10.63.0.5 172.20.20.2 3 u 8 64 7 0.242 0.602 0.365
+10.63.0.6 172.20.20.2 3 u 21 64 7 0.185 0.149 0.368
References
<NOTE:1431693.1> - Pillar Axiom: How to Enable SSH Access on the Pilot(s)
Attachments
This solution has no attachment