nakivo backup failed "target repository is inaccessible"

Not specified by the original author.

TL;DR

Open the Nakivo repository view and check whether the repository shows inaccessible, detached or failed, then test the path from the transporter that owns it. Fix the share, mount, credential or transporter service problem, refresh the repository, and run a small job before the full schedule. Do not create a replacement repository and abandon the existing backup history until the path test proves it is really gone.

nakivo backup failed "target repository is inaccessible"

Use this when

• Nakivo Backup and Replication jobs fail with target repository is inaccessible.
• The repository is on a NAS, SMB or NFS share, or a local disk on a transporter host.
• The repository worked until a NAS reboot, share change or transporter update.

Not for this skill when

• The source VM cannot be snapshotted. That failure happens before any repository write and has a different log signature.
• The repository disk has failed physically with read errors across the volume. Plan storage recovery instead of a refresh.
• A different Nakivo instance should own the repository. Reassigning ownership is an inventory change, not a path fix.

Steps

1. In the Nakivo configuration inventory open the repository and record its type, its assigned transporter, the exact path or share, and the state Nakivo reports. Run the built in repository refresh or verification action if offered and save the detailed message it returns. Verify: you have the repository path, owning transporter and Nakivo current state written down, plus the detailed refresh result
2. From the transporter host itself, not from the director or your workstation, test the repository path: browse the local directory or mount the SMB or NFS share, list existing Nakivo repository folders, and create and delete a small test file. Many inaccessible reports are a transporter side mount that did not return after a reboot. Verify: the transporter can list the existing repository content and write a test file at the exact path Nakivo uses
3. Check the stored access entry Nakivo uses for that repository against any NAS credential rotation, share rename or permission change. If the share was renamed or moved, update the repository location to the new path in Nakivo rather than recreating the share under the old name without a plan. Verify: the access test from the transporter uses the same stored entry as Nakivo and succeeds without interactive prompts
4. Check free space and filesystem health on the repository volume, and confirm the transporter service is running and connected to the director. A full volume or a transporter that dropped after an update presents as inaccessibility in job logs while the share itself looks fine from elsewhere. Verify: the volume shows usable free space, the filesystem reports no errors, and the transporter shows online in Nakivo inventory
5. Refresh the repository in Nakivo so it rescans the existing backup data and updates its state, then check the repository size and last backup records match what you saw on disk. If refresh warns about missing files, stop and investigate storage loss rather than forcing jobs to continue. Verify: the repository returns to an accessible state with its existing backups listed and no missing file warnings
6. Run the smallest backup job that uses this repository and watch it write new data, then run a recovery or file level restore test from an older backup in the same repository to prove reads as well as writes. Re enable the normal schedule only after both pass. Verify: a new backup completes into the repository and a test restore from an existing backup opens correctly

Why it happens

Nakivo separates the director, which schedules jobs, from transporters, which actually read and write repository data. A job therefore reports the repository as inaccessible when the transporter cannot reach the path even though the director and an administrator workstation can. NAS reboots that drop mounts, share permission changes, rotated NAS accounts, a full repository volume and transporter service faults all sit on that transporter to repository leg. Refreshing before the path is proven just repeats the failure, and recreating the repository orphans the existing backup history that a simple mount or credential fix would have preserved.

Variants and edge cases

Repository self healing and verification can take a long time on large repositories and may look like another hang. Start the refresh during a window and watch its progress in activities rather than restarting the transporter mid scan. Also check repository exclusivity: a repository attached to another Nakivo instance or opened by a second transporter can present as inaccessible until ownership is clarified.

nakivo repository inaccessible after NAS reboot

The mount variant. The transporter lost its SMB or NFS mount or its service started before the NAS was ready; remounting and refreshing usually restores it.

nakivo target repository is inaccessible SMB share permission

Use when the share is visible but writes fail. Test with the exact stored account from the transporter host, not with an administrator login.

nakivo repository detached refresh failed

Use when refresh also fails. Separate a path problem from repository content damage by listing the repository folders on disk before any repair action.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSGMKPpJPDGOoIkvE12ISw

Resolved from the public thread: https://vectle.com/posts/pstSGMKPpJPDGOoIkvE12ISw

Thread query: nakivo backup failed "target repository is inaccessible"

TL;DR: Open the Nakivo repository view and check whether the repository shows inaccessible, detached or failed, then test the path from the transporter that owns it. Fix the share, mount, credential or transporter service problem, refresh the repository, and run a small job before the full schedule. Do not create a replacement repository and abandon the existing backup history until the path test proves it is really gone.