Forum Discussion
Write into Google Cloud Storage from Copy Job/Copy Activity within Fabric
my view is the issue is not with Fabric’s copy activity itself but with GCS auth and endpoint configuration. Also, fabric currently has limited support for GCS writes using HMAC authentication. The issue you are seeing, “403 Forbidden” or “TrustFailure” happens because Fabric’s copy activity expects an S3 compatible endpoint with a valid SSL certificate, while GCS’s signed certificate only matches storage.googleapis.com, not bucket-specific URLs.
Key points to know:
Supported setup
Use S3 connector in Fabric with the GCS HMAC key/secret.
Set endpoint to https://storage.googleapis.com.
Enable virtual-hosted-style addressing (<bucket>.storage.googleapis.com) only if SSL trust is established (not always valid for 3rd party buckets).
Required permissions in GCS
roles/storage.objectAdmin (read/write/delete on objects).
Ensure the HMAC key belongs to a service account tied to that role, not a user account.
Workaround for writes
If direct write fails, stage files in Fabric Lakehouse or ADLS, then push to GCS using a Notebook (Python + boto3) or custom REST API with the HMAC signature.
In short, Fabric copy activity can read from GCS via HMAC, but write support is unreliable unless done through a notebook using an S3-compatible client like boto3.
Super Usermy view is the issue is not with Fabric’s copy activity itself but with GCS auth and endpoint configuration. Also, fabric currently has limited support for GCS writes using HMAC authentication. The issue you are seeing, “403 Forbidden” or “TrustFailure” happens because Fabric’s copy activity expects an S3 compatible endpoint with a valid SSL certificate, while GCS’s signed certificate only matches storage.googleapis.com, not bucket-specific URLs.
Key points to know:
Supported setup
Use S3 connector in Fabric with the GCS HMAC key/secret.
Set endpoint to https://storage.googleapis.com.
Enable virtual-hosted-style addressing (<bucket>.storage.googleapis.com) only if SSL trust is established (not always valid for 3rd party buckets).
Required permissions in GCS
roles/storage.objectAdmin (read/write/delete on objects).
Ensure the HMAC key belongs to a service account tied to that role, not a user account.
Workaround for writes
If direct write fails, stage files in Fabric Lakehouse or ADLS, then push to GCS using a Notebook (Python + boto3) or custom REST API with the HMAC signature.
In short, Fabric copy activity can read from GCS via HMAC, but write support is unreliable unless done through a notebook using an S3-compatible client like boto3.