Author name: Managecast Technologies

When a backup job fails with the errors “Failed to open storage for read/write access” or “File does not exist,” it typically indicates that Veeam was unable to access or write to the backup repository. These issues are often caused by connectivity problems, permission misconfigurations, insufficient storage, or file locks that prevent normal access. Common Causes and Resolutions Cause 1: Repository or Storage Connectivity Issues If Veeam cannot reach or communicate properly with the repository, it will fail to open the backup file for read/write operations. Resolutions: Cause 2: Insufficient Free Space When the repository runs out of space, Veeam cannot write incremental or full backup data, often producing the same error message. Resolutions: Cause 3: Permissions or Ownership Issues If the credentials Veeam uses do not have sufficient rights on the repository, the job may fail to open or write to the storage file. Resolution: Cause 4: File Locks or Interference from Other Software Antivirus, backup agents, or volume snapshot tools may lock Veeam backup files (.vbk, .vib, .vrb), preventing read/write operations. Resolutions: Advanced Troubleshooting If the above resolutions do not resolve the issue: Preventive Recommendations If you continue to experience errors after performing these steps, please contact Support@Managecast.com for assistance.

During an update or upgrade of Veeam Backup & Replication, you may encounter the error message: “SSPI authentication failed for user.” Even when running the installer or updater with administrative privileges, this issue can still occur. It’s most often related to a mismatch between the Windows account used for the original installation and the one currently running the update, or to a change in the system hostname after installation. Common Scenarios Case 1: Hostname Changed After Installation If the Veeam installation was performed under a local administrator account and the server’s hostname was later changed, the mapping in PostgreSQL’s authentication file (pg_ident.conf) no longer matches the current system identity. As a result, the SSPI handshake fails during authentication. Case 2: Different Administrator Account Used If the update is being run under a different administrator account than the one originally used for installation, the PostgreSQL service will reject authentication due to an unmatched user mapping. Resolutions Case 1: Edit the pg_ident.conf File 1. Open the file:C:\Program Files\PostgreSQL\15\data\pg_ident.conf(Note: The PostgreSQL version number may vary depending on your installation.) 2. Scroll to the bottom of the file and locate the section labeled:MAPNAME SYSTEM-USERNAME PG-USERNAME You can also add additional administrator accounts here if multiple users manage the environment. 3. Update the entries to reflect the current system username or hostname. Example: 4. Save the file and restart the PostgreSQL-Veeam service. 5. Rerun the installer or update process. Tip: Always create a backup of pg_ident.conf before making changes. Case 2: Run the Updater with the Original Admin Account 1. Log in using the same Windows administrator account that was used during the initial Veeam installation. 2. Re-run the updater or installer from that session. 3. Once the update completes successfully, verify that all Veeam services start normally and can access the configuration database. Additional Notes If the SSPI authentication error persists after applying these fixes, please contact Support@Managecast.com for further assistance.

Symptoms After starting a SureBackup job, it stops almost immediately with the following error: Error: No host is compatible with the virtual machine. When a host leaves Maintenance Mode, is patched, or experiences a temporary issue (i.e., outages, hiccups), the powered off virtual lab can lose its “home” host. From vCenter’s point of view, the VM now sits inside the vApp folder but is orphaned—no ESXi host currently owns it. The moment Veeam asks vCenter to start the appliance, the placement engine evaluates every host in the cluster, finds no valid target, and throws the “No host is compatible” fault. Quick Fix  In your vCenter:  SureBackup’s “No host is compatible”, in most cases, is simply an orphaned lab appliance. A quick migration—even to the same host—will help associate the virtual lab with the host and fix this error. For further assistance, contact our support team at support@managecast.com.