v1.45.0

July 2026 (Version 1.45.0, build 20260730.9)

Welcome to Storage Explorer version 1.45.0. This release focuses on bug fixes to improve quality and reliability across blobs, ADLS Gen2, sign-in, and file shares.

For the full list of fixes, see the 1.45.0 milestone.

Sign-In and Authentication

• Fixed a sign-in failure on macOS (Apple Silicon) that affected some centrally managed devices (#9118).
• Addressed an advapi32.dll login failure reported on macOS (#9051).

Blobs and ADLS Gen2

• Restored the Copy URL command for blobs and files (#9115, #9136).
• Added a Copy Path command to copy a blob or file's path (#9134).
• Opening a blob container with 10,000+ blobs now honors the configured Load Batch Size instead of stopping at 5,000 (#9075).
• The address bar now returns to the container name after clearing the tag filter (#9121).
• The View Options panel can now be closed when opened from the Versions view (#9120).
• Cross-account copy progress for ADLS Gen2 no longer reaches 100% before the copy actually finishes (#9110).
• Propagating access control lists no longer errors for SAS-attached ADLS Gen2 containers with list-only permissions (#9078).

File Shares and Attached Accounts

• Creating a new folder in a file share opened from Quick Access now works (#9083).
• Attached accounts no longer disappear after a manual refresh on Linux (#8902).

File Preview

• The Parquet file preview now uses a different underlying library. Behavior should be unchanged; if you notice any difference when previewing Parquet files, please let us know (#9094).

v1.44.0

June 2026 (Version 1.44.0, build 20260626.6)

Welcome to Storage Explorer version 1.44.0. This release focused on bug fixes to improve quality and reliability of sign-in, AzCopy transfers, and SAS attach experiences.

For the full list of fixes, see the 1.44.0 milestone.

Sign-In and Authentication

• Storage Explorer now recognizes .NET 10 runtimes installed by Homebrew on macOS, restoring sign-in for users on that configuration (#8997, #9008).
• Fixed a "Could not find a WAM account for the selected user" error on Windows (#9060).
• Re-authenticating to an existing account now succeeds in cases where the prompt previously failed silently (#9053).
• Resolved a race condition that produced an immediate re-authentication prompt right after sign-in (#9011).
• Addressed a generic authentication-error path that surfaced for some users (#9006).

AzCopy and Data Transfer

• Upload and download work again on storage accounts that have a SAS expiration policy enforced (#8845).
• Downloading from a virtual directory whose name is empty no longer fails (#8744).
• The Activities pane no longer goes blank during large transfers (#8986).
• Blob deletes against hierarchical-namespace (HNS) accounts using a container or account SAS now invoke AzCopy correctly instead of silently succeeding without deleting anything (#9048).

SAS Direct Links and Attach

• Attaching with a SAS direct link to a subdirectory now navigates to that subdirectory instead of opening the container root (#9001).

Managed Disks

• The Download command is now disabled for disks that Azure rejects for SAS read access, including disks that are attached, reserved, frozen, or in any upload-related state (#9009). Previously, only attached disks were excluded, so download attempts against the other states failed without a clear reason.

v1.43.0

April 2026 (Version 1.43.0, build 20260407.6)

Welcome to Storage Explorer version 1.43.0. This is a release focused on addressing these issues.

AzCopy Upgraded to 10.32.2

Storage Explorer now uses AzCopy 10.32.2, which resolves issues with transfer cancellation for blobs, ADLS Gen2, and file shares (#8933).

Asterisk Key Expands Tree Branches

Pressing the asterisk (*) key now expands all sibling branches at the current level in the tree view, following the WAI-ARIA treeview keyboard interaction pattern (#8987).

Cross-Tenant Copy Fix

Server-side copy transfers between storage accounts in different tenants no longer fail with 403 AuthorizationFailure (#8970).

Linux: Ubuntu 24.04 Base Upgrade

The Linux builds of Storage Explorer are now built on Ubuntu 24.04 (previously 22.04).

Snap

The snap package has been updated from core22 to core24. Since the snap bundles all of its dependencies and runs in a self-contained environment, no action is required from snap users. Updates will be applied automatically through the Snap Store. Linux users on older distributions, including Ubuntu 22.04, can continue to use the snap distribution.

Tarball (.tar.gz)

The tarball now requires Ubuntu 24.04 or later. Users on Ubuntu 22.04 or earlier will not be able to run this version of the tarball. If you have issues launching Storage Explorer, make sure the following packages are installed on your system:

• iproute2
• libasound2t64
• libatm1t64
• libdrm2
• libgbm1
• libnspr4
• libnss3
• libpulse0
• libsecret-1-0
• libx11-xcb1
• libxcb-dri3-0
• libxss1
• libxtables12
• libxtst6
• xdg-utils

v1.42.0

March 2026 (Version 1.42.0, build 20260317.3)

Welcome to Storage Explorer version 1.42.0. This version adds some new features for sharing resources and addresses these issues.

SAS Direct Links

Storage Explorer now supports SAS-based direct links. A SAS-based direct link looks just like an ordinary SAS URL, except it has the storageexplorer: protocol. For example:

• Blob container: storageexplorer://acct.blob.core.windows.net/container?sig=...
• File share directory: storageexplorer://acct.file.core.windows.net/share/dir1?sig=...
• Blob: storageexplorer://acct.blob.core.windows.net/container/dir1/blob.txt?sig=...

When following a direct link, Storage Explorer can automatically attach at the container root, attach at the target item’s directory, download the target item, or download and open the item.

To create a SAS direct link, just take an ordinary SAS URL and change the protocol to storageexplorer:. Keep in mind that only container (sr=c) or share (sr=s) resource SAS URLs are supported, due to permission requirements. If you want the direct link to point to a directory, blob, or file within the container or share, just add the path to the item as part of the URL.

Here is a table summarizing the different types of SAS direct links and their supported operations in Storage Explorer.

Service	Target Item (path)	SAS Resource (sr)	SAS Permissions (sp)	Attach (root)	Attach (target)	Download	Download & Open
Blob/DFS	Container	c	l	✅	❌	❌	❌
Blob/DFS	Blob	c	rl	✅	✅	✅	✅
Blob/DFS	Directory	c	rl	❌	✅	✅	✅
Blob/DFS	Blob	b	N/A	❌	❌	❌	❌
File Share	Share	s	l	✅	❌	❌	❌
File Share	File	s	rl	❌	❌	✅	✅
File Share	File	f	N/A	❌	❌	❌	❌
Queue	Queue	N/A	r	✅	❌	❌	❌
Table	Table	N/A	r	✅	❌	❌	❌

HTTPS Connections with Azurite

Azurite supports HTTPS communications using self-signed certificates. Storage Explorer can now detect and automatically connect to Azurite containers configured to use HTTPS.

In order for Storage Explorer to communicate successfully, you need to add the self-signed certificate to your system's certificate store. You also need to import the certificate into Storage Explorer. You can do this from the Edit → SSL Certificates → Import Certificates menu.

New Feedback Experience

In this version, we've streamlined the experience to make it easier to report issues, open service requests, and provide feedback via our survey. The Feedback button in the vertical toolbar now opens a dialog with these options:

• Report issue - opens the Storage Explorer GitHub issues page.
• Get help - navigates to the Azure Portal's "Help + support" page.
• Help us improve - opens the Storage Explorer feedback survey.

macOS PKG Installer

Starting with 1.42.0, we now distribute PKG installers for macOS users. The installer distribution provides a standard installation process. This is particularly useful for enterprise scenarios.

The PKG installer is now the recommended method for installing Storage Explorer on macOS. We will continue to distribute bare app bundles for updating from older versions. Going forward, Storage Explorer auto-updates will download PKG installers.

macOS Distribution No Longer Bundled with .NET

In addition, we no longer bundle the .NET runtime with the macOS version of Storage Explorer. This significantly decreases the app size and gives users more control over which versions of .NET they wish to use.

.NET is still a required component. You can install .NET by visiting the official .NET website.

Updated to .NET 10

Storage Explorer now requires .NET 10 (updated from .NET 8). On Windows, the installer will automatically install the .NET 10 runtime if it is not already present, so no action is needed. The Linux Snap distribution is self-contained and also requires no action.

For macOS and Linux tar.gz users, you will need to install the .NET 10 runtime separately.

v1.41.1

February 2026 (Version 1.41.1, build 20260214.2)

Welcome to Storage Explorer version 1.41.1. This version updates the bundled version of .NET to 8.0.24 and addresses these issues.

Version 1.41.1 includes all features, improvements, and bug fixes from 1.41.0, which completes support for NFS files and brings improvements to Azurite container support. For a detailed list of all issues closed in 1.41.0, visit our Issues page.

v1.41.0

January 2026 (Version 1.41.0, build 20260130.7)

Welcome to Storage Explorer version 1.41.0. This version completes support for NFS files and brings improvements to Azurite container support.

For a detailed list of all issues closed, visit our Issues page.

NFS File Share Support

This version of Storage Explorer includes AzCopy 10.31, which enhances support for NFS file shares. In addition to features introduced in version 1.40.0, you can now:

• Transfer files and directories between NFS and SMB file shares.
• Preserve symlinks when transferring files (symlinks remain percent encoded when downloaded, see #8841).
• View POSIX properties for files and directories in the Properties dialog.

Azurite Instances in Docker and Podman Containers

Version 1.36.0 introduced support for automatically detecting and connecting to Azurite instances running in local Docker containers. Version 1.41.0 extends this support to include Podman containers.

Configuring Azurite Communication Channels

To add support for both Docker and Podman, Storage Explorer now detects Azurite containers differently. Instead of invoking the Docker or Podman CLI, Storage Explorer communicates directly with the Docker and Podman engines via their named pipes (Windows) or Unix domain sockets (Linux and macOS).

By default, Storage Explorer looks in the following locations for these communication channels:

Platform	Locations
Windows	\\.pipe\docker_engine
	\\.pipe\podman-machine-default
macOS	/var/run/docker.sock
Linux	/var/run/docker.sock
	~/.docker/run/docker.sock

For custom setups, you can add or modify locations using the new Azurite Communication Channels setting (services.storageAccounts.containerSocketPaths).

Linux Snap Support

For Linux snap users, the Docker snap dependency has been removed. You no longer need to have the Docker snap installed for this feature to work.

The snap sandbox environment prevents Storage Explorer from accessing system files. You can work around this by opening a socket that forwards communications to the Docker or Podman engine using socat:

1. Verify the location of the container engine socket (for example, /var/run/docker.sock).
2. Create a forwarding socket within an accessible location, such as your home directory:

   socat UNIX-LISTEN:$HOME/docker.sock,fork UNIX-CONNECT:/var/run/docker.sock​ &

3. Launch Storage Explorer.
4. Modify the Azurite Communication Channels setting to include the absolute path to the forwarding socket (in this case, /home/<username>/docker.sock​).
5. Refresh the Emulators & Attached node.

Note:

• The forwarding socket must be opened in a location that Storage Explorer can access, such as your home directory.
• The forwarding socket must not be a hidden file (that is, its name can't start with a dot).
• You must enter an absolute path to the forwarding socket for the Azurite Communication Channels setting. You can't use expanding shell characters, such as "~".
• If you terminate the background process launched by socat, Storage Explorer won't be able to communicate with the container engines to find Azurite instances.

Improvements for Managing Custom Environments

If you sign in to a custom Azure environment, it's now easier to configure essential environment properties. In addition to the ARM management endpoint, you can also specify audience endpoints, the Microsoft Graph endpoint, and the Azure Service Management (ASM) endpoint. These values are optional and can be autofilled.

Electron 39

Storage Explorer now uses Electron 39. You can learn more from the Electron blog.

Known Issues

If you have installed the Linux snap for the first time, there is a known issue where Storage Explorer may not remember new attachments or proxy credential updates. You can work around these issues by closing and relaunching Storage Explorer. For more information, see #8652 and #8902.

v1.40.2

October 2025 (Version 1.40.2, build 20251101.1)

Welcome to Storage Explorer version 1.40.2. This release updates the bundled version of .NET to 8.0.21 and fixes an issue users may have encountered when trying to sign in to Azure China or Azure US Government clouds.

Version 1.40.2 includes features and bug fixes from 1.40.0. For a detailed list of all issues closed, visit our Issues page.

Downloading from NFS File Shares

In Storage Explorer version 1.40.0, we introduced support for uploading and downloading files from NFS file shares on Linux systems. Some users may have encountered issues when downloading files from NFS file shares. The files are downloaded, but the operation appears to fail in Storage Explorer.

AzCopy will not download anything from an NFS file share unless the --preserve-permissions option is provided. This option instructs AzCopy to preserve the original file's ownership on the local machine. However, this requires running AzCopy with sudo, because AzCopy needs to change file ownership, which requires elevated privileges. Storage Explorer cannot invoke AzCopy with sudo. This leads to the issue where downloads appear to fail regardless of settings.

If you encounter this issue, you can work around it by copying the AzCopy command and executing it directly from the command line with sudo.

This issue will be addressed in a future version of Storage Explorer.

Electron 38

Storage Explorer now uses Electron 38. You can learn more from the Electron blog.

v1.40.0

September 2025 (Version 1.40.0, build 20250925.27)

Welcome to Storage Explorer version 1.40.0. This release adds new features for file shares and tables. For a detailed list of all issues closed, visit our Issues page.

NFS File Shares

Storage Explorer now supports working with NFS file shares. If you have access to Premium File storage accounts, you can now manage NFS file shares in those accounts.

In this release, Storage Explorer supports the following operations:

• Create NFS file shares. Storage Explorer will ask you whether you want to create an SMB or an NFS file share after entering the name of the new file share.

• Copy and paste NFS file shares between storage accounts.

• Create, manage, and delete NFS file share snapshots.

• Copy and paste files and folders between NFS file shares. Transfers between NFS and SMB, SMB and NFS, NFS and blob, and blob and NFS will be available in a future release.

• Upload to or download from NFS file shares (Linux only; Windows and macOS support will come in a future release).

We've also updated the Transfers → Preserve Info and Transfers → Preserve Permissions settings to reflect the NFS changes. We recommend enabling these settings when uploading or downloading from NFS file shares. This will help prevent ownership issues when downloading files.

When downloading from NFS file shares, AzCopy will attempt to modify the ownership of the local file to match the ownership of the file in the NFS file share. Errors may occur if your Linux user is not the owner. You can work around ownership-related errors by copying the AzCopy command used by Storage Explorer and run it directly from the command line using sudo.

Azure support for NFS file shares is ongoing. We will continue to improve NFS support as more platform features become available.

JSON Support for Table Import/Export

Storage Explorer now supports the option of importing and exporting table data in JSON format. JSON is better suited for developer workflows than CSV.

JSON Format

The expected JSON format is similar to the payload format for table service operations:

[
  {
    "PartitionKey": "p1",
    "RowKey": "r1",
    "Value1": "1",
    "Value1@type": "Int32",
    "Value2": "1.4",
    "Value2@type": "Edm.Double",
    "Value3": "true",
    "Value3@odata.type": "Boolean",
    "Value4": "example",
    "Value4@type": "Edm.String"
  },
  {
    "PartitionKey": "p1",
    "RowKey": "r2",
    "Value1": "2",
    "Value2": "1.5"
  }
]

Type annotations are optional and can be expressed using the @type or @odata.type suffixes. Type values can include the Edm. prefix.

To prevent data loss, Storage Explorer expects all values to be represented as JSON strings. This helps prevent precision errors when parsing numbers, such as large Int64 values or certain Double values.

Storage Explorer can infer data types without type annotations, but there are situations where the type cannot be unambiguously determined. For example, "123" could be an Int32 or an Int64, and "Jane" could be a Binary or a String. For this reason, we recommend providing type annotations whenever possible.

Using Type Annotations as a Schema

Table imports have also been improved to better handle data that adheres to a schema.

Azure Tables are inherently schemaless—they don't ensure all entities in the table have the same set of properties with the same data types. However, users often model their data using schemas. In such cases, type annotations for all entities in import/export files become redundant.

In this version, we've added the option to export type annotations for the first entity only. This option helps preserve important type information while reducing the size of the exported file.

Storage Explorer can take advantage of files that only have type annotations for the first entity. When you select an import file, the Import dialog samples the first few entities to determine the best types for each property. If you disable the "Infer types for unannotated property values" option, Storage Explorer will select property types based on the type annotations for the first entity in the file.

Note that type sampling might not always work as expected. Storage Explorer may select different types if the sampled data does not match the type annotations from the first entity or if type annotations are present on multiple entities. This can lead to type-related errors during import. Always verify that your data is well formatted and that types can be unambiguously determined for all values.

Multi-factor Authentication Enforcement

Multi-factor authentication (MFA) will soon be required for all create, update, and delete operations. To avoid service interruptions, ensure that MFA is enabled for your user account, or contact your administrator for assistance. Once MFA is enabled, you may need to sign in to Storage Explorer again.

For more information, visit Planning for mandatory multifactor authentication for Azure and other admin portals.

v1.39.1

July 2025 (Version 1.39.1, build 20250715.1, Windows x64 and Windows ARM64 build 20250719.5)

Welcome to Storage Explorer version 1.39.1. This release addresses several additional issues that were not resolved in 1.39.0.

Version 1.39.1 includes feature enhancements and bug fixes from 1.39.0. For a detailed list of all issues closed in 1.39.0, visit our Issues page.

AzCopy for Windows ARM

Storage Explorer for Windows ARM now comes with an ARM-native binary of AzCopy. Windows ARM users can now benefit from improved performance and reduced memory usage when transferring data with AzCopy.

Windows .NET Installation Improvements

To help users keep Storage Explorer components up to date, the Storage Explorer installer for Windows now compares the latest version of the .NET Runtime installed with the version of .NET that comes bundled with Storage Explorer. If the installed version is older than the bundled version, the Storage Explorer will prompt you to install the newer version.

Storage Explorer Snap Base Upgraded to core22

The Storage Explorer snap for Linux has been upgraded to use the core22 base snap. This change was introduced in 1.39.0. For most users, this change is seamless and requires no additional action.

v1.39.0

June 2025 (Version 1.39.0, build 20250624.11)

Welcome to Storage Explorer version 1.39.0. This release includes several feature enhancements and bug fixes. For a detailed list of all issues closed, visit our Issues page.

Direct Link Path Support for File Shares

Storage Explorer now supports direct links to folders in file shares. If you have a direct link to a file share with a path argument for a folder, Storage Explorer will open a tab for that folder.

Currently, there is no "Copy Direct Link" option for file share folders as there is for blobs, so you cannot create direct links to file share folders directly. To do so, you must manually add a path argument to an existing file share direct link. If you would like to see a "Copy Direct Link" feature for file share folders, please open a feature request.

Azurite Container Auto-detection

Storage Explorer uses the docker command to automatically find and connect to Azurite instances running in Docker containers. Podman users who mapped the podman command to docker may have experienced issues with this feature due to differences in output format between Docker and Podman. This issue has now been fixed.

As a result, if you are using Podman and have mapped it to the docker command, Storage Explorer can detect and connect to Azurite instances running in Podman containers. However, functionality may be limited, and full support for Podman containers is still a work in progress.

Storage Explorer and AzCopy Proxy Settings

In previous versions, Storage Explorer provided a separate setting for controlling how the version of AzCopy included with Storage Explorer used a proxy. This created unnecessary complexity and confusion when Storage Explorer and AzCopy proxy settings did not match.

In this release, AzCopy now uses the same proxy settings as Storage Explorer. As a result, we have removed the redundant Transfers → AzCopy → Disable AzCopy Proxy Usage (transfers.azCopy.noProxy) setting.