This article describes causes and solutions for the 'copy' error that occurs while performing an installation of the policy package.
During installation of the policy package, FortiManager needs to copy the used shared objects from the ADOM Database to the Device Database.
If there are any mapping or binding conflicts, the 'copy' error occurs:
Possible causes of the copy error.
The most common cause is a conflict with the interface bind for address objects.
In this example, the 'Test' address object binds with 'port6' under FortiManager. However, the same address is bound as 'any' under FortiGate:
Here, the SKIP flag triggers because these objects are not related to a specific firewall policy.
Solution: The bind-interface needs to be the same interface on both ends.
Note: Changing the interface binding is not possible if the address is used in a firewall policy.
Remove it from the firewall policy to allow it to be changed, then re-add it later.
A similar bind error can also be encountered while importing configuration.
For details, refer to the following document:
Technical Note: Policy Package gets imported incompletely into FortiManager
Using the SD-WAN member interface to firewall policy instead of the SD-WAN interface:
Copy device global objects
Post vdom failed:
error :131 - datasrc invalid. object: firewall policy.1:srcintf. detail: port1.
solution: data cannot be used. reason: invalid value - prop[srcintf]: firewall policy srcintf/dstintf cannot be used in system sdwan members interface(port1).
Solution: In firewall policy 1, the source interface (srcintf) must be replaced by an SD-WAN interface.
Another common cause for the copy error occurs with the VPN Manager. While installing the Policy package, a similar copy error may appear:
resolve dynamic interface port2 failed,dev=3164,vdom=root
failed to update vpn node with device info
Solution: Make sure the 'Default VPN Interface' from the VPN Manager should have valid interface mapping to the remote FortiGate interface.
Another potential cause is that the ADOM version and the FortiGate version may be different.
View Install Log
Device preparation failed:
version mismatched,adom:7.2; dev:6.4
Solution: Make sure the FortiGate major version is the same as the ADOM version.
In this case, the ADOM version is 7.2 and FortiGate is 6.4.x.
To fix the issue, either keep the FortiGate in 6.4 ADOM or upgrade FortiGate to version 7.2.x.
To upgrade the ADOM, refer to the following article:
During installation, if FortiManager finds two objects with the same name, an install copy error will occur.
Solution: To fix this, change the name of one of the objects.
A copy error may also occur when a mapping or default mapping is missing.
Copy objects for VDOM root:
"firewall ssl-ssh-profile", "certificate-inspection", id=2602, SKIP - (null)
"vpn certificate ca", "andersen_CA2", id=3254, COMMIT FAIL - datasrc duplicate
"firewall policy", "1", id=3354, FAIL - Mapping or default mapping not exist. detail: Mapping or default mapping not exist. detail: Local certificate "WTASSubCA-Fortinet" not exist in target device (SN:FGT60FTK20098183)
Solution: Import local certificate WTASSubCA-Fortinet on FortiGate and define per-device mapping in the dynamic object certificate to fix the error.
Download the Installation logs to more easily identify the exact reason for the error.
To get detailed information, run the following command after connecting to FortiManager with SSH:
diag debug application securityconsole 255
diag debug enable
For further troubleshooting, gather the following debug information from FortiManager when trying to push the configuration and attach it to the ticket when contacting TAC.
On the FortiManager:
diagnose debug application securityconsole 255
diag debug app depmanager 255
diagnose debug application fgfmsd 255 <fgt device name>
diagnose debug enable
diagnose debug time enable
On the FortiGate:
exe tac report
diagnose debug application fgfmd 255
diagnose debug cli 255
diagnose debug console time enable
diagnose debug enable