• Hi, Pleskians! We are running a UX testing of our upcoming product intended for server management and monitoring.
    We would like to invite you to have a call with us and have some fun checking our prototype. The agenda is pretty simple - we bring new design and some scenarios that you need to walk through and succeed. We will be watching and taking insights for further development of the design.
    If you would like to participate, please use this link to book a meeting. We will sent the link to the clickable prototype at the meeting.
  • (Plesk for Windows):
    MySQL Connector/ODBC 3.51, 5.1, and 5.3 are no longer shipped with Plesk because they have reached end of life. MariaDB Connector/ODBC 64-bit 3.2.4 is now used instead.
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.

Issue Backup Failures (Error 1920) The file cannot be accessed by the system. The file will not be archived.

CIT

New Pleskian
Server operating system version
Windows Server 2019 Standard Edition (Build 17763) (64-bit) (Release ID 1809)
Plesk version and microupdate number
Plesk Obsidian Version 18.0.53 Update #2
Seeking assistance - receiving warnings in the Backup Manager, one is persistent, and the other one has the same error but for various domains; usually only one per day.

Persistant:
Warning:
Subscription "domain.com.au"
Not all the data from C:\Inetpub\vhosts\domain.com.au"was backed up successfully:
Unable to get attributes of the file C:\Inetpub\vhosts\domain.com.au"\httpdocs\wp-content\plugins\monk-blocks\node_modules\.bin\acorn: (1920) The file cannot be accessed by the system. The file will not be archived.
Unable to get attributes of the file C:\Inetpub\vhosts\domain.com.au"\httpdocs\wp-content\plugins\monk-blocks\node_modules\.bin\ansi-html: (1920) The file cannot be accessed by the system. The file will not be archived.
Unable to get attributes of the file C:\Inetpub\vhosts\domain.com.au"\httpdocs\wp-content\plugins\monk-blocks\node_modules\.bin\autoprefixer: (1920) The file cannot be accessed by the system. The file will not be archived.
Unable to get attributes of the file C:\Inetpub\vhosts\domain.com.au"\httpdocs\wp-content\plugins\monk-blocks\node_modules\.bin\browserslist: (1920) The file cannot be accessed by the system. The file will not be archived.
Unable to get attributes of the file C:\Inetpub\vhosts\domain.com.au"\httpdocs\wp-content\plugins\monk-blocks\node_modules\.bin\check-node-version:... (truncated)

Same Error - Just a different domain name each backup:
Warning:
Subscription "domain.com"
Unable to back up files from C:\Inetpub\vhosts\domain.com owned by system user. Error: Failed to create archive:

--

I've performed a DB and permissions repair to no avail.

With thanks,
 
Hi Mark,

Thanks for sending this through, already tried this - the task is not running/ not found.
 
Would it be an option to change the permissions on the files or directory?
I've got direct OS access but I replicated the permissions the same as other websites and all seemed fine. I would've thought the permissions repair tool would resolve this too.

Happy to take your instruction and try this method again if you have some?
 
The culprit is a path within Wordpress. It is possible that themes or plugins set their own permissions for certain paths. Also, the .bin (dot starting path) looks suspicious. You will need to check path and file ownership and permissions in Windows Explorer (or right-click and properties) what this directory has compared to regular paths like wp-content.
 
The culprit is a path within Wordpress. It is possible that themes or plugins set their own permissions for certain paths. Also, the .bin (dot starting path) looks suspicious. You will need to check path and file ownership and permissions in Windows Explorer (or right-click and properties) what this directory has compared to regular paths like wp-content.
Hi Peter,

Thank you for the extra information, I can confirm that all the folders within those directories (and surrounding) have the same Windows folder permissions.

Not sure what you mean by .bin being suspicious. There is another .cache folder in that same directory that does not throw errors.
 
It seems impossible that the permissions and ownerships are identical. In that case the system could access the file as it can access any other file. Could it be thinkable that an antivirus software interferes and blocks access to these files?
 
Back
Top