• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • 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.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

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