No Egress for Serverless Workspace

Janis404 — Mon, 29 Jun 2026 06:12:32 GMT

Hello,

I have a problem

import socket print(socket.gethostbyname("google.com"))

[Trace ID: 00-9e5667936e24418dae4c39a9ed003a22-a43a5f2ca9b14451-00] --------------------------------------------------------------------------- gaierror Traceback (most recent call last) File <command-6578131666108476>, line 2 1 import socket ----> 2 print(socket.gethostbyname("google.com")) gaierror: [Errno -2] Name or service not known

My current Workspace Settings:

- serverless workspace
- ncc for private connectivity. is set (postgres on AWS)
- network policy with egress to all destinations is added to the workspace

SELECT * FROM system.access.outbound_network ORDER BY event_time DESC LIMIT 5;

account_id,workspace_id,destination_type,destination,dns_event,storage_event,event_time,access_type,event_id,network_source_type cd8ca332-b1fd-4a23-8858-bd7726a44c6d,7474659368742910,DNS,ocr.salfyops.com,"{""domain_name"":""ocr.salfyops.com"",""rcode"":5,""rdata"":[]}",null,2026-06-29T05:53:00.000Z,DROP,94f242d5-19c7-487e-a8bb-4340fc2c15b5,General Compute cd8ca332-b1fd-4a23-8858-bd7726a44c6d,7474659368742910,DNS,ocr.dev.salfyops.com,"{""domain_name"":""ocr.dev.salfyops.com"",""rcode"":5,""rdata"":[]}",null,2026-06-29T05:53:00.000Z,DROP,01f60056-3d43-49b0-9b5d-0398bb1caaab,General Compute cd8ca332-b1fd-4a23-8858-bd7726a44c6d,7474659368742910,DNS,ocr.dev.salfyops.com,"{""domain_name"":""ocr.dev.salfyops.com"",""rcode"":5,""rdata"":[]}",null,2026-06-29T05:53:00.000Z,DROP,f24d25aa-9e4f-488f-8973-110b13ed5359,General Compute cd8ca332-b1fd-4a23-8858-bd7726a44c6d,7474659368742910,DNS,ocr.salfyops.com,"{""domain_name"":""ocr.salfyops.com"",""rcode"":5,""rdata"":[]}",null,2026-06-29T05:53:00.000Z,DROP,f3a3b9f1-6113-4ebf-bf92-c20bad404470,General Compute cd8ca332-b1fd-4a23-8858-bd7726a44c6d,7474659368742910,DNS,google.com,"{""domain_name"":""google.com"",""rcode"":5,""rdata"":[]}",null,2026-06-29T05:52:50.000Z,DROP,0d765e3d-70c2-4f80-98ad-05e90c7fc668,General Compute

AI mentioned to me "Just wait for ~15 minutes to avoid re-using a warm compute" - The problem is not solved for many hours now.

Could you give me additional guidance? Please note: I am relying on a serverless workspace. I can't use Classic Compute here.

Thanks!

Re: No Egress for Serverless Workspace

Louis_Frolio — Wed, 15 Jul 2026 19:59:47 GMT

Greetings @Janis404 ,

Nice work pulling system.access.outbound_network and narrowing this to serverless. That table is where the answer lives, so let me walk through what it's telling you.

Read the log rows first:

access_type is DROP, which is real enforcement, not a dry-run entry (dry-run shows up as DRY_RUN_DENIAL). So egress is being blocked right now, not merely recorded.
The rcode: 5 in the dns_event is a DNS REFUSED. The serverless DNS layer refused the lookup, and that is exactly what produces the Python gaierror [Errno -2] Name or service not known. Your code is fine. The block sits upstream of Python.
One nuance: denials are logged to this table even when a policy is in Full access mode, so the presence of rows isn't the smoking gun by itself. The DROP verdict is.

Now the apparent contradiction: the policy screenshot says "Allow access to all destinations," but google.com, a plain public name, is being dropped. Under a Full access policy that's actually in force, that lookup should succeed. Two things explain the gap, and I'd rule them out in this order.

The config you're showing may not be the config that was active when those DROP rows were written. Your policy view and your log output aren't necessarily from the same moment, so pin them together: terminate the serverless environment on the notebook (or start a brand-new serverless run rather than reusing one that's still warm), re-run the socket test immediately, then query outbound_network again and confirm whether there are fresh DROP rows for google.com with new timestamps. This also handles the warm-compute angle: network access mode changes apply to newly provisioned serverless compute, not to a session that was already running when you flipped the setting. The "wait 15 minutes" advice was reaching for this, but 15 minutes is optimistic, and a session that never fully recycles can lag much longer.
If a fresh session still drops it, have an account admin inspect the policy through the account API, CLI, or Terraform and confirm restriction_mode is FULL_ACCESS with no blocked_internet_destinations entries. Databricks lets you block specific domains even while a policy is in Full access mode, so the General tab's radio button doesn't tell the whole story. Check for an entry matching google.com or a broader parent domain. One caveat: a single blocklist entry wouldn't explain your own domains getting dropped too, so if everything is failing, the timing issue above is the likelier culprit than a targeted block.

On the NCC: since you called it out, salfy-prod-ncc is almost certainly not behind these particular rows. A private endpoint rule for your Postgres routes that one FQDN privately by matching its hostname; it doesn't produce a DROP for an unrelated public name like google.com in the egress table. The DROP is an egress policy decision, so that's where to look, not the private-connectivity path.

If you've confirmed Full access on genuinely fresh serverless compute, with no blocked destinations, and it still drops google.com, that no longer matches expected Full access behavior and it's a Support case. Give them everything on the first pass: workspace ID (dbc-6b9d00ae-0ac6), region eu-central-1, the policy name, the outbound_network rows with their timestamps, and a failing run ID, and state plainly that you're serverless-only and Full access is set.

Takeaway: the Python gaierror is a symptom, not the problem. Your logs already show the serverless egress layer refusing DNS, so the fix is getting a Full access policy actually in force on fresh compute, confirmed by fresh DROP-free rows, before you change anything else. Start with a cold session and matching timestamps.

Regards,
Louis

topic Re: No Egress for Serverless Workspace in Administration & Architecture

No Egress for Serverless Workspace

Re: No Egress for Serverless Workspace