I just upgraded to 2.3.0.1_stable_2026-04-24 on Windows 11. When looking at the Source Data settings for a backup, I can no longer browse the local filesystem, instead it’s just a blank box with a computer icon, though clicking the icon does cause it to move and a bit of a blue bar starts moving across the box:
I’ve tried multiple browsers (Chromium and Firefox) and private windows, so I don’t think it’s an extension conflict. And the folders and checkboxes do show up in the legacy interface.
Sounds like something breaks here. What version did you upgrade from?
Can you look in the logs to see if there is anything here that could explain it?
Alternative is to use the Browser Developer tools (F11) and then see if the request reports some kind of meaningful error.
Upgraded from the most recent stable version (2.2?).
Nothing in the logs, but I do see the following error repeatedly in the console:
XHRPOST
http://localhost:8200/api/v1/filesystem?onlyFolders=false&showHidden=true
[HTTP/1.1 500 Internal Server Error 3ms]
It’s often F12 or browser menu will likely have it.
Also keep an eye on icons in lower right, for red.
My Duplicati (various versions) are being variably slow browsing local filesystem.
Delay can vary from almost nothing to about 30 seconds, but blue bar is moving.
Watching developer tools shows all the filesystem server queries finishing, but
2.3.0.0_stable_2026-04-14 gets a 500 error. 2.3.0.1_stable_2026-04-24 does not.
That doesn’t make it faster, but it does avoid the red Alert that “An error occurred”.
Mine’s a little different, but is similar enough I thought it would be worth a mention.
My backups have a local Destination, and 2.3.0.0 also shows a slow browse there.
Opening subfolders is fast, but initial load varies. I thought it might be Windows…
Might be different from yours, but it’s all I can offer – saw something a little similar.
My 500 error is generally on the last filesystem which ends with four backslash.
Earlier ones end with two. Regardless, these are all done fast, then mystery delay.
That should certainly be logged as an error as the processing fails in Duplicati.
Have two tabs with Duplicati open.
In one tab, go to:
http://localhost:4200/about/logs/live
For the “Log level”, choose “Warning”.
Then go to the other tab, and try to browse the files, the log page should now show the errors.
Super strange that those errors are not logged.
These are fine, it is just probing to see if you have any databases or virtual machines that could be backed up, but it is normal that they are not there.
To dig further into this, we need to enable some more extended logging apparently.
Exit Duplicati, then from a commandline (Press Win+R, type cmd, press enter) run these two commands:
> set DUPLICATI_WEBSERVER_LOGGING=1
> "C:\Program Files\Duplicati 2\Duplicati.GUI.TrayIcon.exe"
Duplicati will now start up and the commandline window should be filled with log messages that you can ignore. Then go to browse the files again, and now you should see the error being logged in the commandline window with details on what is causing issues.
If this means that any 500 error should log, mine don’t, even at profiling.
I’d still like to know if @lanxique is getting any red Alert icon with message.
My version analysis of this error (which may or may not be the same) is like:
PASS 2.2.0.105_canary_2026-02-20
PASS 2.2.1.0_beta_2026-03-05
PASS 2.2.0.106_canary_2026-03-06
PASS 2.2.0.107_canary_2026-03-20
FAIL 2.3.0.0_stable_2026-04-14
FAIL 2.3.0.100_canary_2026-04-23
PASS 2.3.0.1_stable_2026-04-24
I’m running Duplicati as a Windows service, so restarting it this way would potentially mean it runs differently. Should I stop the service and run it this way? (And could running as a service be a factor?)
To continue describing my version of the 500 error and slowness but not hang:
Use local filesystem destination, which has the same issues but is controllable.
For brevity, I used C:\tmp\dest500
Rather than run a backup, after setup, see config Destination screen open fine.
If you set F12 developer tools to watch network before clicking destination, get
{"path":"/"}
{"path":"C:\\"}
{"path":"C:\\tmp\\"}
{"path":"C:\\tmp\\dest500\\"}
{"path":"C:\\tmp\\dest500\\\\"}
The latter two respond with [] as the folder is still empty.
The first query is the slow one, causing delays I spoke of.
The last query purpose is unknown, but now I will break it:
Place a file manually in Destination. I created an empty file called empty.txt.
Home, repeat it, and watch. Last query returns 500 Internal Server Error
For my slowness, and maybe hang here, I see first query not show fast status.
When it finishes it shows a Status 200, and Pending in time then shows time.
Here’s an early view where the last query has already failed, and first is going:
First query when finished says it took 1.1 min. Cause is unknown, but weirdly
the delay varies depending on which network my PC is on. One lists / slowly.
EDIT 1:
And for the 500, its weirdness is the way it depends on final folder having file.
EDIT 2:
My OS is Windows. Browser above is Edge, but Firefox shows the same bug.
It did manage to not delay the first query for / once, but did on above repeat.
This test used 2.3.0.100_canary_2026-04-23. Many-versions survey is above.
Some parts seem not entirely predictable though, e.g. above results in Firefox.
That was the intention at least. I will fix it.
The / query needs to list all drives and home folders + HyperV and MSSQL. Could it be that a drive is in power-down mode, and then it needs to wake to be read?
That looks like an error for sure. How do you get the UI to emit that query?
Since the logging of the 500 errors is not working, it will be difficult to get the error message out when running as a service, because the only other option is “log to console” and we cannot get the console of a service. There are also messages logged to the Windows Event Log, but I suspect that this particular issue is not logged there either.
Running as a service should just mean elevated privileges and should not cause problems.
Could you try running a new instance that is not a service, but maybe run it in an admin prompt to try to simulate the environment as much as possible? Something like this:
> set DUPLICATI_WEBSERVER_LOGGING=1
> "C:\Program Files\Duplicati 2\Duplicati.Server.exe" --server-datafolder=C:\something-temporary
Doubt it. This is a desktop with an internal drive that stays on. No USB drives.
After finding a / delay, I just watched in Process Monitor, noting GUI tree time.
Based on time, I think below shows the last actions, and the server response:
This sort of fits with the delay being worse on the network that HP3 lives on.
It sort of doesn’t since it’s slow when PC HP3 is disconnected from network.
There is no reference to this SMB share in this job, but I used it sometimes.
Although all that action is listed as TrayIcon, I’m not sure whose code ran it.
That was described earlier as a job edit, then analyze a click on Destination.
Source click acts similarly. I’d encourage @lanxique to test with destination.
Also please check lower right corner of screen to see if Alert shows an error.
Below are its last two requests in 2.3.0.0_stable_2026-04-14 with an old job:
{"path":"C:\\Program Files\\Duplicati 2\\"}
{"path":"C:\\Program Files\\Duplicati 2\\\\"}
This was a click on Source. Just like Destination, last request gets 500 error.
This TrayIcon is running in a terminal, and isn’t doing any output at 500 time.
Application and Services log for Duplicati 2 isn’t logging an interesting event.
EDIT 1:
I’m not sure what the “error for sure” was on the last query. If you mean two
trailing backslashes (before web encoding), I think this follows the previous
design of adding one trailing backslash, except now earlier queries add one
which means that the last query gets two.
{"path":"C:\\Duplicati\\duplicati-2.2.0.3_stable_2026-01-06-win-x64-gui\\RUN\\test 1"}
{"path":"C:\\Duplicati\\duplicati-2.2.0.3_stable_2026-01-06-win-x64-gui\\RUN\\test 1\\"}
are the last two queries on 2.2.0.3. The / is slow here too. That makes me
wonder whether something external to Duplicati has changed its behavior…
Is this from a slow run? Looking at the timestamps, this was completed in less than a second (assuming it started with the first CreateFile). I do see some LanmanRedirector calls that could be slow if it has to reach a remote destination. Am I reading it right?
Took me quite a while to figure out what that meant 
.
You need a saved backup with some folders that are not the “My Documents” and similar.
Then simply visit the page and all loads as expected, but in the background an extra request is made for a // folder.
Found and fixed it.
No. The entire run is about 13,000 events, and I only showed the parts that
seemed to be when something loosened up and allowed GUI to do display.
I have a theory now, based on PowerShell (and maybe Explorer) with delay.
In the below, there’s a 1 minute gap before the S: last line shows on screen:
PS C:\> Get-PSDrive -PSProvider FileSystem
Name Used (GB) Free (GB) Provider Root CurrentLocation
---- --------- --------- -------- ---- ---------------
C 875.52 55.45 FileSystem C:\
D FileSystem D:\
G 878.29 52.68 FileSystem G:\
S FileSystem \\HP3\Shared
PS C:\>
The delay is gone if I do a repeat immediately, and in the middle if I delay a bit.
This is kind of the behavior I see with Duplicati, where / delays entire display.
C:\>net use
New connections will be remembered.
Status Local Remote Network
-------------------------------------------------------------------------------
Disconnected S: \\HP3\Shared Microsoft Windows Network
The command completed successfully.
C:\>
These commands just show the drive letters, and they seem to have no delay:
C:\>wmic logicaldisk get caption
Caption
C:
D:
G:
S:
C:\>fsutil fsinfo drives
Drives: C:\ D:\ G:\ S:\
C:\>wmic logicaldisk get caption
Caption
C:
D:
G:
S:
C:\>
I suppose the test with PowerShell is another one that @lanxique could try.
As a C# app (like Duplicati), it might share some behaviors from similar use.
Explorer shows this share with what looks like a disconnected icon, like this:
I don’t know what updates this. Right click menu is slow but has Disconnect.
I’m not immediately going to push that in case some more testing is needed.
I tried these instructions; it created a new instance of Duplicati that worked but did not have access to my setup. In creating a backup job there I was able to browse the local filesystem normally.
Makes sense, as Duplicati does not return partial results like the commandline, so it buffers the entire response and then returns it.
Duplicati uses DriveInfo to enumerate the drives. It reads DriveType, IsReady, VolumeLabel and RootDirectory.
To counter the issue you see, Duplicati filters by IsReady, but it looks like the drive is “ready” in some sense.
One thing that I notice is that the slow command is showing the Root directory, which is also what Duplicati does, so perhaps reading this piece of information requires some slow call?
Based on the C# example, I have this machine translated PS script:
$allDrives = [System.IO.DriveInfo]::GetDrives()
foreach ($d in $allDrives) {
Write-Host "Drive $($d.Name)"
Write-Host " Drive type: $($d.DriveType)"
Write-Host " Volume label: $($d.VolumeLabel)"
Write-Host " Root directory: $($d.RootDirectory)"
if ($d.IsReady) {
Write-Host " File system: $($d.DriveFormat)"
Write-Host (" Available space to current user: {0, 15} bytes" -f $d.AvailableFreeSpace)
Write-Host (" Total available space: {0, 15} bytes" -f $d.TotalFreeSpace)
Write-Host (" Total size of drive: {0, 15} bytes" -f $d.TotalSize)
}
Write-Host ""
}
Could you play around with the script and comment out lines so we can figure out what properties are “safe” to call?
Ok, so it is most likely related to something that is different when running in the service context. Is the service running in the SYSTEM account?
Unfortunately the long 30 to 60 second delay has gone. It’s now about 5 seconds.
Duplicati does still vary from maybe 2 to 7 seconds, and a repeat soon is about 0.
Regardless, here’s a run of the original script:
PS C:\bin> .\GetDrives.ps1
Drive C:\
Drive type: Fixed
Volume label:
Root directory: C:\
File system: NTFS
Available space to current user: 56013082624 bytes
Total available space: 56013082624 bytes
Total size of drive: 999618043904 bytes
Drive D:\
Drive type: CDRom
Volume label:
Root directory: D:\
Drive G:\
Drive type: Fixed
Volume label: Google Drive
Root directory: G:\
File system: FAT32
Available space to current user: 53212426240 bytes
Total available space: 53212426240 bytes
Total size of drive: 999618043904 bytes
Drive S:\
Drive type: Network
Volume label:
Root directory: S:\
Delay I’m talking about here is on S: after Drive type. Above and below are fast.
I suppose I could swap Volume label and Root directory to see where delay is…
Now Root directory is instant, and the delay is before Volume label (last output).
Yes, it’s running as the Local System account.
One additional data point: I tried creating a new backup job, with files from the same drive, running on the same instance of Duplicati, and the file browser opened fine, so it’s something about the source data for the other backup that is causing problems. (All the source directories are C:\Something.)
If the delay gets more pronounced, maybe we can revisit. For now I am thinking that it should be possible to avoid the volume label. Maybe we can do “get in 1s or ignore” so we have a max delay of N seconds where N is the number of drives.
Looking back, I think I mixed your report with the input from @ts678 .
When you see in the browser console:
http://localhost:8200/api/v1/filesystem?onlyFolders=false&showHidden=true
Could you check the “Request” tab and see if the path sent to the server is strange?
Alternative is to do the following:
I’ve played around with it a little further, and don’t see anything odd in the requests that pop the error. I also tried paring down the list of sources to one folder, and that didn’t help.
However, after further experimentation it seems like the issue is actually with the excluded folders/files, not the included ones.
I’ve tried clearing the Filters list, and the browser displays again. I can add a few more filters back and it works, but when I start adding more back in the browser stops working. Some of the old list of excluded folders included ones that no longer exist, but I haven’t yet figured out exactly which combination it is that causes the issue. But it seems like that’s the culprit.