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
- Check the logged AWS error code for the root cause.
- Validate credentials and region configuration of the S3 filesystem.
- Grant s3:GetObject and s3:ListBucket on the bucket to the IAM user.
- Handle foreign-account buckets (they return 403, not 404) explicitly.
- 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
- Keep server clocks synced (signature skew)
- Use region-aware endpoints (s3.<region>.amazonaws.com)
- Grant both s3:ListBucket and s3:GetObject to the VFS credentials
- Rotate credentials before expiry for long-running jobs
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
- vfs.provider/get-type.error
- FileSystemException wrapping SdkClientException
- vfs.provider.local/create-folder.error
- vfs.provider.s3/transfer.error
- Exception getting the list of buckets
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)