Alerts and Errors on Linux

This section lists the alerts and errors that may be encountered during system operations.

Encryption key on device has not been made available

This alert may appear as the reason for a GuardPoint not to have been enabled. The message appears in the output of secfsd -status guard command. The status indicates that the encryption key specified in the policy for the GuardPoint has not been made available to the protected host.

Solution: Check the host's connectivity with the Key Manager.

Specified policy disagrees with metadata set on the Guard Path

This alert may appear as the reason for a GuardPoint not to have been enabled. The message appears in the output of secfsd -status guard command. The status indicates that the key specified in the policy for the GuardPoint does not match with the key stored in the IDT Device Header.

Solution: Un-guard the device and check the name and UUID of the key in the IDT Device Header using voradmin idt status <device-name> and voradmin idt status xform <device-name> commands and compare the name and UUID with the key name specified in the policy. Correct the discrepancy and re-guard the device.

Device has not been configured for IDT-Capable

This alert may appear as the reason for a GuardPoint not to have been enabled. The message appears in the output of secfsd -status guard command. The status indicates that the device has been properly guarded as an IDT-Capable GuardPoint on the Key Manager but the device has not been initialized for guarding as IDT-Capable.

Solution: The most probable cause of this error is that you did not initialize the device for guarding as IDT-Capable on protected host. It's also possible that the guarded device has already configured for guarding as Ean IDT-Capable GuardPoint. If the device needs to be initialized for guarding as IDT-Capable, see Initializing an IDT-Capable Device.

Device not resized for guarding as IDT-Capable

This message appears in the output of secfsd -status guard command and indicates that the IDT-Capable GuardPoint was not successfully enabled. The status indicates that the newly guarded IDT-Capable GuardPoint, which has been initialized with xform option of voradmin, has not been resized to accommodate storage space for the CTE Private Region.

Solution: Unguard the IDT-Capable GuardPoint, resize the LUN and verify that the host sees the expanded size, then guard the IDT-Capable GuardPoint from the Key Manager.

Data transformation failed

This message appears in the output of secfsd -status guard command and indicates that the IDT-Capable GuardPoint was not successfully guarded. The status indicates that the protected host encountered an error while transforming the data on the device during IDT.

Solution: Consult with the system and/or storage admin to check on the health of the LUN in the storage array. You may contact Thales Support for troubleshooting and recovery if there has not been a report of any error on the LUN.

Data transformation in progress

This message appears in the output of secfsd -status guard command and indicates that the IDT-Capable GuardPoint was not successfully enabled. The status indicates that the protected host is transforming the data on the device.

Solution: You must wait for data transformation to complete. Check the status of transformation by running voradmin idt status xform <device name>. Access to the device is blocked until transformation completes.

Device <device-name> is configured to guard as IDT-Capable GuardPoint

This error message is reported by the voradmin command when initializing a device as an IDT-Capable GuardPoint that has already been initialized for guarding as an IDT-Capable GuardPoint.

Solution: The device has already been initialized for guarding as IDT-Capable and is probably waiting to be guarded as an IDT-Capable GuardPoint through the Key Manager. Alternatively, if you want to remove the IDT-Capable configuration, use the voradmin idt delete <device-name> command.

Device <device-name> is configured as IDT-Capable GuardPoint

This error message is reported by the voradmin command when initializing a device that is already being guarded as an IDT-Capable GuardPoint.

Solution: The device is already guarded by an IDT-Capable GuardPoint.

GuardPoint for device <device-name> still guarded on Key Manager

This error message is reported by the voradmin command when attempting to initialize a device for rekey or removing the device as IDT-Capable.

Solution: Unguard the IDT-Capable GuardPoint, wait for the protected host to process the update, and then rerun the voradmin command.

Failed to open device <device-name>, error Device or resource busy

This message occurs when voradmin detects that the target device is busy.

Solution: The device may already be in use by other application. Rerun the voradmin command when the device is no longer in use.

Device <device-name> is not configured as IDT-Capable

This error message is reported by the voradmin command when attempting to delete a device as an IDT-Capable GuardPoint.

Solution: This message indicates that the target device has been not initialized for guarding as IDT-Capable. The message may also be reported if the specified device has been initialized for guarding as IDT-Capable but it has not been guarded yet. In this case, it removes the preparation made by voradmin. You can remove the IDT-Capable configuration status on the device by running voradmin idt delete <device-name>. You may see the same error message again, and if you do, you can ignore it.

Abort! Error: Could not stop secfs, secvm device(s) busy

This error occurs during CTE shutdown when there is a busy CTE protected device.

Solution: Verify that all applications directly accessing secvm protected GuardPoints have been shut down. Ensure that all file systems on top of a secvm protected devices are under the control of systemd and have been unmounted before attempting to shut down the agent.

Abort! Error: Could not unmount file systems

This error occurs during CTE shutdown when a file system under the control of systemd fails to unmount.

Solution: Verify that file systems on top of an IDT-Capable GuardPoint devices are not busy and then rerun the agent shut down command.

A dependency job for idt.mount failed. See 'journalctl -xe' for details

This error occurs during CTE startup when system fails to mount a file system. This error message is typically accompanied by a long timeout during the CTE startup process.

Solution: Check that the underlying device is available and that the IDT-Capable GuardPoint was successfully applied on the device. Once the device is available, the file system will automatically finish mounting.

ESG/IDT-ALERT: IO error on header for [GuardPoint]

This is an alert message to the Key Manager. It occurs when CTE encounters a general error when attempting to access the private region on an IDT-Capable device.

Solution: An I/O error attempting to read or write to the device may have been caused by errors on the host or storage array. Consult with the system and/or storage admin to check on the health of the LUN in the storage array. You may contact Thales Support for troubleshooting and recovery if there has been no report of errors on the LUN.

ESG/IDT-ALERT: Data transformation failure on [GuardPoint]

This is an alert message to the Key Manager. It occurs when protected host encounters an error transforming the data on device during IDT process.

Solution: Contact Thales Support for troubleshooting and recovery.

ESG/IDT-INFO: Data transformation complete on [GuardPoint]

This message is a notification to the Key Manager admin that the protected host has completed the data transformation of the specified IDT-Capable GuardPoint.

ESG/IDT-ALERT: Failed to resize <device-name>

This alert is a notification to the Key Manager admin that the protected host has failed to update the change to the device size in the IDT Device Header on the device.

Solution: Contact Thales Support for troubleshooting and recovery.

FSADM-ALERT: ESG/IDT required Signature Set for system utilities may have to be resigned

This alert is a notification to the Key Manager admin that the recent system upgrade to the protected host may have updated the binary files listed in the signature set for restricting root access.

Solution: Upon this notification you must immediately re-sign the affected or all the binary files to prevent them from accessing protected data.

File System is not automatically mounted after IDT completes

An IDT-Capable device with a file system that has been configured to automatically mount may fail to automatically mount while the device undergoes data transformation through IDT. Following is a sample log message in the kernel ring buffer that reports a failed attempt to access a device during IDT. You can ignore this message.

Vormetric SecVM: secvm_map during IDT ((dc 00000000c3537611)

When access to a device is to mount the file system, the kernel ring buffer may also report a second error message indicating that a file system failed to mount due to data corruption. You can ignore this message. This occurs because the mount command is issued after the device has been guarded but before data transformation through IDT is complete. While IDT is in progress, the device cannot be used, so any attempt to mount the file system will fail.

Solution: Manually mount the file system after IDT is complete.