mount cifs volume on all purpose compute results in permission denied

[158576]

I have all networking already set, nslookup resolves NAS server IP and connectivity is enabled from worker nodes to nas server. I am able to mount the same nas drive outside of databricks, I mean standalone linux vm in the same VPC where worker nodes configured,

[siva-anantha]

Hello, 
Could you provide with more information about why you want to attach NAS drive to Databricks cluster, please? 

I am no expert in Storage. As far as I understand, NAS will suffer with IO and Replication Bottlenecks, when attached to Distributed compute environments. Please review this aspect. 

[Ashwin_DSA]

Hi @158576,

Sorry for the delay in getting back to you, and just closing the loop in case you’re still expecting an answer. Thanks for sharing the details. Based on what you’ve already validated, this does not sound like a basic networking problem. If nslookup works, worker nodes can reach the NAS host, and the same share mounts successfully from a Linux VM in the same VPC, then the more likely issue is that the failure is happening at the Databricks compute/runtime layer rather than at DNS or network routing.

In practice, mounting a CIFS/SMB share from inside Databricks all-purpose compute is not a typical supported access pattern. Public Databricks documentation around containerised compute is a useful clue here.... Databricks Container Services for dedicated compute is specifically documented for dedicated compute, and its limitations note that it is not supported on standard access mode compute. So even when network reachability is in place, that does not automatically mean OS-level mount operations such as CIFS mounts will succeed from within Databricks compute.

For supported file-based access patterns, Databricks generally recommends using Unity Catalog on top of cloud object storage instead. For non-tabular files, Databricks recommends Unity Catalog volumes, and the docs explicitly say volumes are the recommended way to govern access to non-tabular data. If you need to work with existing cloud storage directories, external volumes are the relevant option, and they are created against an external location in object storage. More generally, Unity Catalog uses external locations to govern access to cloud storage paths and the credentials used to access them.

So...what you are seeing is expected behaviour for the Databricks runtime environment, rather than evidence that your NAS server or network path is misconfigured. If the end goal is to move data between Databricks and the NAS, the usual workaround is to use an intermediate process outside Databricks, such as a VM, container, or integration service that can mount the SMB share directly, and then exchange data with cloud object storage that Databricks can access through Unity Catalog.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.