File Browser is winding down and this is the last planned release. The repository is archived on 2026-09-01. After that date there will be no further releases, bug fixes, or security fixes. Existin...
I wonder how viable it would be to do the opposite of quantum. If we remove every at risk feature and strip it down to the basics: no scripts, no multi-user, no public sharing etc…
Project could be pretty easy to maintain indefinitely?
Really? I never tried the original but didn’t have much problems setting up quantum. I had to modify my caddy file somewhat to suite my needs, but just works now.
No changes to the container image, but I had to fiddle with the config file. There is an option (tokenExpirationHours) to set for how long a token is valid, default is 2 hours. I can only find this in the commented example config, setting it to sometime really high like 50 let my friend upload his audiobooks without problems.
Create a config file and place it somewhere the container can access it. Then add the environment variable FILEBROWSER_CONFIG=/some/path/to/your/config.yaml.
Here is a snippet from my config:
server:# ...auth:tokenExpirationHours:50# ...userDefaults:fileLoading:maxConcurrentUpload:100# The inferface only shows up to 10 so I don't know if setting this value higher does anythinguploadChunkSizeMb:10
Thanks for that. I grinned at the pitch; 'It’s a no-compromise solution that’s a a quantum leap forward. Looking at the rest of the page, it does seem to have some bases covered with features. So, naturally, I’m going to have to check it out. Bookmarked.
There is a fork though: File Browser Quantum https://filebrowserquantum.com/
How does this compare to copyparty?
I wonder how viable it would be to do the opposite of quantum. If we remove every at risk feature and strip it down to the basics: no scripts, no multi-user, no public sharing etc…
Project could be pretty easy to maintain indefinitely?
I’ve tried to use quantum and it lost the “just works” factor that OG filebrowser has. Not sure what I’ll do now
Really? I never tried the original but didn’t have much problems setting up quantum. I had to modify my caddy file somewhat to suite my needs, but just works now.
Did you make any modifications for large file uploads? My main problem was that big files (As in 5GB) would fail.
No changes to the container image, but I had to fiddle with the config file. There is an option (tokenExpirationHours) to set for how long a token is valid, default is 2 hours. I can only find this in the commented example config, setting it to sometime really high like 50 let my friend upload his audiobooks without problems.
Create a config file and place it somewhere the container can access it. Then add the environment variable
FILEBROWSER_CONFIG=/some/path/to/your/config.yaml.Here is a snippet from my config:
server: # ... auth: tokenExpirationHours: 50 # ... userDefaults: fileLoading: maxConcurrentUpload: 100 # The inferface only shows up to 10 so I don't know if setting this value higher does anything uploadChunkSizeMb: 10tokenExpirationHours is the key to set.
Thanks! I’ll give it a go at some point, I greatly appreciate the help :)
Thanks for that. I grinned at the pitch; 'It’s a no-compromise solution that’s a a quantum leap forward. Looking at the rest of the page, it does seem to have some bases covered with features. So, naturally, I’m going to have to check it out. Bookmarked.