apache/hadoop · error · AbfsRestOperationException

FNS-Blob rename was not successful for source and destinatio

Error message

FNS-Blob rename was not successful for source and destination path: {} & {}

What it means

On non-HNS accounts, rename is emulated by BlobRenameHandler (copy + delete pipeline). If handler.execute() does not report success, AbfsBlobClient throws a client-synthesized AbfsRestOperationException with HTTP 500, AzureServiceErrorCode.UNKNOWN, and message 'FNS-Blob rename was not successful for source and destination path: <src> & <dst>'. The 500 originates in the driver, not the Azure service — the concrete per-blob cause is in the handler's logs.

Source

Thrown at hadoop-tools/hadoop-azure/src/main/java/org/apache/hadoop/fs/azurebfs/services/AbfsBlobClient.java:866

      throws IOException {
    BlobRenameHandler blobRenameHandler = getBlobRenameHandler(source,
        destination, sourceEtag, isAtomicRenameKey(source), tracingContext
    );
    try {
      if (blobRenameHandler.execute(false)) {
        final AbfsUriQueryBuilder abfsUriQueryBuilder
            = createDefaultUriQueryBuilder();
        appendSASTokenToQuery(source, SASTokenProvider.RENAME_SOURCE_OPERATION,
            abfsUriQueryBuilder);
        final URL url = createRequestUrl(destination,
            abfsUriQueryBuilder.toString());
        final List<AbfsHttpHeader> requestHeaders = createDefaultHeaders();
        final AbfsRestOperation successOp = getSuccessOp(
            AbfsRestOperationType.RenamePath, HTTP_METHOD_PUT,
            url, requestHeaders);
        return new AbfsClientRenameResult(successOp, true, false);
      } else {
        throw new AbfsRestOperationException(HTTP_INTERNAL_ERROR,
            AzureServiceErrorCode.UNKNOWN.getErrorCode(),
            ERR_RENAME_BLOB + source + SINGLE_WHITE_SPACE + AND_MARK
                + SINGLE_WHITE_SPACE + destination,
            null);
      }
    } finally {
      incrementAbfsRenamePath();
    }
  }

  @VisibleForTesting
  BlobRenameHandler getBlobRenameHandler(final String source,
      final String destination,
      final String sourceEtag,
      final boolean isAtomicRename,
      final TracingContext tracingContext) {
    return new BlobRenameHandler(source,
        destination, this, sourceEtag, isAtomicRename, false, tracingContext);

View on GitHub (pinned to 2add963021)

Solutions

  1. Verify the source path still exists, then retry the rename
  2. Check credential scope: the key/SAS must allow read+delete on source and write on destination
  3. Look at driver logs for the per-blob failure the handler reported and address that specific error
  4. For rename-dominated workloads, move to an HNS-enabled account where rename is an O(1) metadata operation
Defensive patterns

Strategy: try-catch

Validate before calling

if (!fs.exists(srcPath)) {
  throw new FileNotFoundException("rename source missing: " + srcPath);
}
fs.rename(srcPath, dstPath);

Try / catch

try {
  fs.rename(src, dst);
} catch (AbfsRestOperationException e) {
  // client-synthesized 500 from BlobRenameHandler: check handler logs for per-blob cause,
  // verify source still exists, then retry with bounded backoff
}

Prevention

When it happens

Trigger: fs.rename() on a flat-namespace account where the blob-rename pipeline fails: source blob deleted mid-copy, SAS token lacking copy/delete permissions, unresolvable rename-pending markers, or transient failures inside the handler.

Common situations: Rename-heavy workloads on non-HNS accounts (slow and failure-prone); SAS-scoped credentials without delete on source or write on destination; concurrent deletes racing the copy; huge directories with many rename-pending markers.

Related errors


AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/99caf62e45f50fc4. Report an issue: GitHub.