Hello, dear!
Good day to you!
This case describes one of the possible causes of the video retrieval exception, that is, the recording retrieval fails because the permission does not match after the device upgrade.
Problem Description
Upgrade VCN 3020 from V1R2C50SPC222 to V1R3C10. After the upgrade is complete, most cameras can retrieve recordings of only one day but cannot retrieve historical recordings.
Problem Analysis
Problem locating
The MU module (media management module) logs are analyzed. Because the idle recording blocks are insufficient, the MU performs recording block recycling. After the recording block is reclaimed, the MU detects that the available recording space is still insufficient. The MU module recycling operation is triggered cyclically. As a result, historical recording index files are repeatedly deleted. (The MU module does not reclaim the recording blocks of the latest day. Therefore, the MU cyclically recycles historical recordings.)
Analyze the reason why space is still insufficient after the MU recording is reclaimed. Analyzed the logs of the Safevideo module. It was found that the SafeVideo failed to reclaim the recording block. As a result, the recording block was not recycled successfully. Therefore, the MU recording space was insufficient.
Check the reason why the recording module fails to be reclaimed. When reclaiming a recording module, the user who performs the recycling operation has insufficient permission. As a result, the recycling operation cannot be performed. As shown in the following figure, the permission of the recording file is root, and the ivsmu user cannot reclaim the file.
Compared with the V1R2C50 and V1R3C10, the V1R3C10 performs security hardening on user rights. The MU module of the V1R2C50 version runs as the root user. The block file created by the MU module belongs to the root user, and the file permission is 700. The MU module of the V1R3C10 version runs as the ivsmu user. Therefore, the permission of the root user is still required for reclaiming historical blocks. However, in V1R3C10, the permission of the ivsmu user is changed.
Because the index file of historical recordings is deleted, only one day of recording files can be retrieved on the client. The actual historical recording data is not deleted. You can restore the historical recording data by using the restoration method.
Impact: The permission after the upgrade is inconsistent with that before the upgrade. Only one day of recording files can be retrieved on the client.
The following figure shows the problem flowchart:
Resolution of issues
Change the startup permission of mu to root to resolve the problem.
Use the tool to re-create indexes to restore the indexes of historical recordings. After the restoration, most recordings can be retrieved and played back, and some recordings are still interrupted.
Reconstruct the recording index by scanning the data block. During the reconstruction, all data disks are scanned.
After the disk scanning is complete, recreate the database index of the recording block.
Root Cause
Two versions have different policies for permission control. After the upgrade, the recording block operation rights are inconsistent. After the upgrade, the recording block permission is not modified. As a result, the normal recording index file is deleted. As a result, only one day of historical recordings can be queried after the upgrade, most historical recordings cannot be retrieved.
Corrective Action
Raise the startup permission of the mu module to the root permission to avoid permission inconsistency. When reclaiming recording blocks, ensure that recordings can be recycled properly.
Optimize the data restoration tool to ensure that the restored data is properly marked. Otherwise, recordings cannot be retrieved due to abnormal recycling of the mu.
Best wishes!
