![]() | Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
![]() |
||||||||||||||||||
Solution Type Problem Resolution Sure Solution 2210719.1 : Oracle ZFS Storage Appliance: Sendbundle fails with error: An executable file was detected in your uploaded file
In this Document
Created from <SR 3-13655620591> Applies to:Sun ZFS Storage 7120 - Version All Versions and laterOracle ZFS Storage ZS3-2 - Version All Versions and later Sun Storage 7310 Unified Storage System - Version All Versions and later Sun Storage 7410 Unified Storage System - Version All Versions and later Sun ZFS Storage 7320 - Version All Versions and later 7000 Appliance OS (Fishworks) SymptomsOracle support will routinely request support bundles from customers to assist with diagnosis and repair of problems. The procedures from Document 1019887.1 Sun Storage 7000 Unified Storage System: How to Collect a Support Bundle using the BUI or CLI, are followed. Instead of successfully attaching to the SR in My Oracle Support (MOS), the following error is logged: An executable file was detected in your uploaded file 3-xxxxxxxxxxx_ak.e7bf8721-0d94-4abe-9403-c9385c07bbf5.tar.gz.
For security reasons, Oracle does not accept executable files. Therefore, file 3-xxxxxxxxxxx_ak.e7bf8721-0d94-4abe-9403-c9385c07bbf5.tar.gz has been deleted from our systems. Please remove all executable files from your upload bundle and resubmit. You can find additional information on our Oracle's file management practices at https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&id=1227943.1
CauseBeginning on Nov 11, 2016, the Oracle repository for all uploaded data will reject an entire bundle is any file in the uncompressed bundle contains one of the following suffixes.
SolutionOracle support can assist in locating and deleting (or renaming) the files for you. Given that the bundles are deleted after uploading to MOS, its important to generate a bundle ahead of time and NOT automatically upload to MOS.
Once the bundle is created, saved locally, and unzipped, files can be located via simple search techniques. In the following example a bundle named ak.3cee47dd-4cd2-4a4d-ba53-df9ac4fc923e.tar.gz is saved off to a local Solaris client. Once saved, the files were found using the du command: # gzcat ak.3cee47dd-4cd2-4a4d-ba53-df9ac4fc923e.tar.gz | tar -xvf -
# du -a ak.3cee47dd-4cd2-4a4d-ba53-df9ac4fc923e | egrep -i 'com$|aspx$|bat$|exe$' x ak.3cee47dd-4cd2-4a4d-ba53-df9ac4fc923e/logs/20160929174229.20160930162449.s7320.us.oracle.com
The offending file was located in the logs directory of the appliance. Oracle support can rename this file for you in a webex or shared shell (remote access) session. In this particular case, there were files ending in .com because the name of the system defined in Configuration -> Services -> Identity -> Show was a fully qualified name, i.e. s7320.us.oracle.com. The system identity was changed to the short name - s7320 - and the offending files re-named. Other causes for this problem do exist and can be handled on a case by case basis. You can rename all these files in the log directory with the following command. ZFS> confirm shell find /var/ak/logs -name "*.com" -exec bash -c 'mv "$1" "${1}.old" ' -- {} \;
Checked for relevancy - 09-May-2018
Attachments This solution has no attachment |
||||||||||||||||||
|