I'm looking for advice on how to reliably access a subfolder of an on-premises network share from a time-triggered Azure Function. The goal is to fetch files, process them, and then move them either to a backup folder or create new files. This needs to be a two-way sync; deletions and new file creations should reflect both in the Azure Function and the on-prem share.
Previously, a quick solution was implemented using Logic Apps and an on-premises data gateway, but it has limitations, especially with file sizes over 20 MB. My customer needs to handle files that are around 50 MB, which has resulted in a complex setup with Azure Data Factory involved.
I want to transition this to a cleaner architecture involving Azure Functions, but I've hit a snag. Even with VNET integration that allows on-prem access, I can't access network folders since Azure Functions are sandboxed and block the SMB protocol.
Using blob storage seems problematic because there are other ERP systems depending on the existing folder structure, which wouldn't work with blobs. While Azure File Shares might be an option, I'm uncertain if they can be mounted directly onto an existing path instead of a drive letter, and I'm also considering Azure File Sync.
Additionally, I'd like to know if there's a way to utilize the File Shares client library for .NET without running into limitations. Is mounting storage in the function configuration any better than using the client library? Maybe I'm overthinking this? If anyone has set up a reliable solution for this kind of integration, your input would be greatly appreciated!
2 Answers
Yep, you can actually mount Azure Files as a disk! It seems to strike a good balance for integrating with on-prem setups, so definitely worth trying out.
If your Azure Function has vnet integration and you’ve set up a site-to-site VPN correctly, it should work. Just make sure the on-prem server's hostname is resolvable from the function’s vnet, which you can manage with a private DNS setup. Also, ensure you have a local account ready to authenticate with the SMB server.
I tried that, but I got an access error. The vnet setup might not have been correct. Other functions connecting to on-prem SQL and FTP servers on the same vnet do work. I found a Kudu article that mentions that certain ports needed for SMB might be blocked on Windows sandboxes, so I wonder if a Linux function could work in this case.