pentaho/pentaho-kettle · error · FileSystemException

vfs.provider/get-type.error

vfs.provider/get-type.error

Error message

vfs.provider/get-type.error

What it means

S3CommonFileObject.doAttach() determines the file type. When the S3 call used to check whether the path is a bucket/key fails with anything other than 'not found'-style codes, it logs 'Could not get information on <name>' and throws FileSystemException('vfs.provider/get-type.error', cause, name). Only paths judged to be folders fall through to injectType(FOLDER).

Solutions

  1. Check the logged AWS error code for the root cause.
  2. Validate credentials and region configuration of the S3 filesystem.
  3. Grant s3:GetObject and s3:ListBucket on the bucket to the IAM user.
  4. Handle foreign-account buckets (they return 403, not 404) explicitly.
  5. Add retry logic for transient 5xx errors.

Example fix

// before
throw new FileSystemException( "vfs.provider/get-type.error", e, getQualifiedName() );
// after
if ( e instanceof AmazonServiceException && e.getStatusCode() >= 500 ) {
  retryAttachWithBackoff();
} else {
  throw new FileSystemException( "vfs.provider/get-type.error", e, getQualifiedName() );
}
Defensive patterns

Strategy: try-catch

Validate before calling

// probe account/bucket before attach
try {
  s3.getObjectMetadata( bucketName, key );
} catch ( AmazonS3Exception e ) {
  if ( e.getStatusCode() != 404 && !"NoSuchKey".equals( e.getErrorCode() ) ) {
    throw new IllegalStateException( "S3 attach will fail: " + e.getErrorCode() );
  }
}

Try / catch

try {
  FileObject fo = fs.resolveFile( path );
  fo.getType();
} catch ( FileSystemException e ) {
  logger.debug( "attach failed for {}", path, e.getCause() );
  // distinguish 403 (permissions) from 5xx (retryable)
}

Prevention

When it happens

Trigger: doAttach() when the backing S3 request (getObjectMetadata / bucket existence check) fails with AccessDenied, InvalidAccessKeyId, signature errors, timeouts, or any non-'NoSuchKey/404' error.

Common situations: Wrong region endpoint causing 301/403, IAM missing s3:ListBucket/s3:GetObject, expired credentials in long-running Pentaho servers, proxy blocking AWS endpoints.

Related errors


AI-assisted analysis of pentaho/pentaho-kettle@f3058517a1 (2026-09-13). Data as JSON: /api/errors/225fdfa23bedb7a0. Report an issue: GitHub.

Appendix: source

Thrown at plugins/s3-vfs/core/src/main/java/org/pentaho/s3common/S3CommonFileObject.java:246

    if ( isRootBucket() ) {
      // cannot attach to root bucket but still need to figure out the type for exists()
      try {
        fileSystem.getS3Client().getBucketLocation( bucketName );
      } catch ( AmazonS3Exception e ) {
        if ( "NoSuchBucket".equals( e.getErrorCode() ) ) {
          injectType( FileType.IMAGINARY );
          return;
        }

        // One common case is "403 Access Denied", for bucket names which exist in the same region
        // but are not of this account. This can also happen for normal files and is being handled
        // similarly in handleAttachExceptionFallback.
        // Any other errors should also bubble up.

        // Make sure this gets printed for the user.
        logger.error( "Could not get information on {}", getQualifiedName(), e );
        throw new FileSystemException( "vfs.provider/get-type.error", e, getQualifiedName() );
      }

      injectType( FileType.FOLDER );
      return;
    }

    try {
      // 1. Is it an existing file?
      s3ObjectMetadata = fileSystem.getS3Client().getObjectMetadata( bucketName, key );
      injectType( getName().getType() ); // if this worked then the automatically detected type is right
    } catch ( AmazonS3Exception e ) { // S3 object doesn't exist
      // 2. Is it in reality a folder?
      handleAttachException( key, bucketName );
    } finally {
      closeS3Object();
    }
  }

View on GitHub (pinned to f3058517a1)