OrchardCMS/OrchardCore · error · FileStoreException

Cannot get file stream of the file

Error message

Cannot get file stream of the file '{path}'.

What it means

GetFileStreamAsync wraps any non-FileStoreException failure during blob download (after the exists check) in a FileStoreException with this message. The inner exception holds the underlying Azure Storage RequestFailedException explaining the real cause.

Solutions

1. Inspect the InnerException (RequestFailedException) for the HTTP status: 403 = credentials, 404 = deleted between check and read, 429/503 = throttling, retry with backoff.
2. Verify storage credentials and connection string are valid and have read access to the container.
3. Retry the operation for transient failures (timeouts, 5xx) rather than treating them as permanent.
4. Check network connectivity/firewall rules between the app server and the storage account.

Example fix

// before
var stream = await fileStore.GetFileStreamAsync(path); // may throw
// after
try
{
    var stream = await fileStore.GetFileStreamAsync(path);
}
catch (FileStoreException ex) when (ex.InnerException is RequestFailedException rfe && rfe.Status >= 500 || rfe?.Status == 429)
{
    // retry with backoff
}

var file = await fileStore.GetFileInfoAsync(path);
if (file == null) return null;

try
{
    var stream = await fileStore.GetFileStreamAsync(path);
}
catch (FileStoreException ex) when (ex.InnerException is RequestFailedException rfe && (rfe.Status >= 500 || rfe.Status == 429))
{
    // transient — retry with backoff
}
catch (FileStoreException ex)
{
    logger.LogError(ex.InnerException, "Permanent failure reading {Path}", path);
    throw;
}

When it happens

Trigger: Calling IFileStore.GetFileStreamAsync(path) when the Azure SDK download throws — storage auth failure (403), container missing, network timeout, throttling (429/503), or the blob was deleted between the ExistsAsync check and the download.

Common situations: Expired or revoked storage account keys/SAS tokens; storage account unreachable from the server (firewall, DNS); race conditions where a concurrent request deletes the blob mid-download; transient Azure service errors.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors

• Cannot copy file ' ' to ' '.
• Cannot create file ' '.
• Cannot create a stream for a directory.
• Error retrieving file info for
• Error creating directory

AI-assisted analysis of OrchardCMS/OrchardCore@4306c0717f (2026-09-13). Data as JSON: /api/errors/36a4b9003aaa9b2e. Report an issue: GitHub.

Appendix: source

Thrown at src/OrchardCore/OrchardCore.FileStorage.AzureBlob/BlobFileStore.cs:648

    {
        try
        {
            var blob = GetBlobReference(path);

            if (!await blob.ExistsAsync())
            {
                throw new FileStoreException($"Cannot get file stream because the file '{path}' does not exist.");
            }

            return (await blob.DownloadAsync()).Value.Content;
        }
        catch (FileStoreException)
        {
            throw;
        }
        catch (Exception ex)
        {
            throw new FileStoreException($"Cannot get file stream of the file '{path}'.", ex);
        }
    }

    // Reduces the need to call blob.FetchAttributes, and blob.ExistsAsync,
    // as Azure Storage Library will perform these actions on OpenReadAsync().
    public Task<Stream> GetFileStreamAsync(IFileStoreEntry fileStoreEntry)
    {
        return GetFileStreamAsync(fileStoreEntry.Path);
    }

    public async Task<string> CreateFileFromStreamAsync(string path, Stream inputStream, bool overwrite = false)
    {
        try
        {
            var blob = GetBlobReference(path);

            if (!overwrite && await blob.ExistsAsync())
            {

View on GitHub (pinned to 4306c0717f)