![IBM Storwize V7000 Problem Determination Manual Download Page 281](http://html.mh-extra.com/html/ibm/storwize-v7000/storwize-v7000_problem-determination-manual_4062780281.webp)
During the USB initialization of the Storwize V7000 Unified system, one of the
node canisters in the control enclosure creates a public/private key pair to use for
ssh. The node canister stores the public key and writes the private key to the USB
key memory.
One of the file modules then takes the private key from the USB key memory to
use for ssh. The file module passes it to the other file module over the direct
connect Ethernet link and then deletes the private key from the USB key memory
so that it cannot be used on the wrong system.
It might be necessary to reset the NAS ssh key in the following circumstances:
v
When communications between the Storwize V7000 file module and the
Storwize V7000 control enclosure is not authorized because of a bad key.
v
When both Storwize V7000 file modules have lost the original NAS ssh key.
v
When the Storwize V7000 control enclosure has lost the NAS ssh key.
Perform the following steps to reset the NAS ssh key so that the communications
between the file modules and the Storwize V7000 control enclosure resume:
1.
Log on to the Storwize V7000 control enclosure management CLI as
superuser
:
satask chnaskey -privkeyfile NAS.ppk
The private key is left in the
/dumps
directory.
2.
Use SCP to copy the private key file to the /files directory on the file module
which is currently the active management node:
scp -P 1602 /dumps/NAS.ppk root@<active file module IP>:/files
You are prompted for the file module root password.
3.
Log on to the Storwize V7000 Unified management CLI as
admin
:
chstoragesystem --sonasprivkey /files
Working with NFS clients that fail to mount NFS shares after a
client IP change
Use this information to resolve a
refused mount
or
Stale NFS file handle
response to an attempt to mount Network File System (NFS) shares after a client IP
change.
After a client IP change, a
df -h
command returns no results as shown in the
following example:
Filesystem
Size
Used Avail Use% Mounted on
machinename: filename:
-
-
-
-
/sharename
Also, you can see the following error from the
ls
command:
ls: .: Stale NFS file handle
Also, the hosting file module in the Storwize V7000 Unified system displays the
following error:
mgmt002st001 mountd[3055867]: refused
mount
request from hostname for sharename (/): not
exported
If you receive one of the errors above, perform the following steps:
1.
Access the file module that hosts the active management node role using root
privileges. Then issue the following command to flush the NFS cache in each
file module:
onnode all /usr/sbin/exportfs -a
.
Chapter 7. Recovery procedures
257
|
|
|
Summary of Contents for Storwize V7000
Page 6: ...vi Storwize V7000 Unified Problem Determination Guide Version...
Page 8: ...viii Storwize V7000 Unified Problem Determination Guide Version...
Page 10: ...x Storwize V7000 Unified Problem Determination Guide Version...
Page 18: ...xviii Storwize V7000 Unified Problem Determination Guide Version...
Page 24: ...xxiv Storwize V7000 Unified Problem Determination Guide Version...
Page 32: ...8 Storwize V7000 Unified Problem Determination Guide Version...
Page 274: ...250 Storwize V7000 Unified Problem Determination Guide Version...
Page 278: ...254 Storwize V7000 Unified Problem Determination Guide Version...
Page 296: ...272 Storwize V7000 Unified Problem Determination Guide Version...
Page 306: ...282 Storwize V7000 Unified Problem Determination Guide Version...
Page 312: ...288 Storwize V7000 Unified Problem Determination Guide Version...
Page 313: ......
Page 314: ...Printed in USA GA32 1057 04...