October 30, 20223 yr Author @NeldonadomI'm honestly not an unRaid expert so I don't know if using a cache vs not would be the cause of this issue. In my case I have all my videos on a share that is not using a cache. This is what I map in /mnt/user/files/videos I could see this being an issue if you are not mapping in a path off of your /mnt/user directory.
April 21, 20233 yr Hey there! Giving this docker a go but it doesn't seem to scan folders recursively. Any chance that could be added or will be added in the future? I keep my video files organized and don't want them all dumped into one folder. Thanks! ~K
April 21, 20233 yr Author 1 hour ago, Keek Uras said: Hey there! Giving this docker a go but it doesn't seem to scan folders recursively. Any chance that could be added or will be added in the future? I keep my video files organized and don't want them all dumped into one folder. Thanks! ~K Fireshare already handles scanning for video files recursively. You don't need to have them all in a single folder. However, on the frontend it will categorize all your videos based on the top level folders name. So if your media is structured like this... /media/game_1/awesome_clips/my_awesome_game_1_clip.mp4 /media/game_1/funny_clips/my_funny_clip.mp4 /media/game_1/random_clip.mp4 /media/game_2/awesome_clips/my_awesome_game_2_clip.mp4 /media/game_2/weird_stuff/weird_clip.mp4 The front-end web app will give you these categories that all of your clips will show up under. game_1/ my_awesome_game_1_clip my_funny_clip random_clip game_2/ my_awesome_game_2_clip weird_clip
April 22, 20233 yr 16 hours ago, Shane Israel said: Fireshare already handles scanning for video files recursively. You don't need to have them all in a single folder. However, on the frontend it will categorize all your videos based on the top level folders name. So if your media is structured like this... /media/game_1/awesome_clips/my_awesome_game_1_clip.mp4 /media/game_1/funny_clips/my_funny_clip.mp4 /media/game_1/random_clip.mp4 /media/game_2/awesome_clips/my_awesome_game_2_clip.mp4 /media/game_2/weird_stuff/weird_clip.mp4 The front-end web app will give you these categories that all of your clips will show up under. game_1/ my_awesome_game_1_clip my_funny_clip random_clip game_2/ my_awesome_game_2_clip weird_clip It just took a lot longer to show up than expected. It is working. Thanks.
August 17, 20232 yr I've since deleted some of the videos that were originally scanned and located by Fireshare, but now they are obviously showing up as "FILE MISSING". How can I scan for files that are no longer present or even just instruct it which files are no longer there?
August 17, 20232 yr Author @Cheezelz Fireshare uses its database as the source of truth. So if you don't delete your files using fireshare it will think that the file is missing (i.e maybe a drive didn't mount, or it moved, etc, etc). So in your case to remedy the issue, you can do this in one of two ways currently. 1. On every file in Fireshare that says "File Missing" click the edit button (pencil icon) and choose "Delete". This will delete the file and all associated data (thumbnail, symlink, db entry). 2. If you have too many "Missing File" files that you don't want to have to manually delete using method 1, you can instead stop the fireshare container and then delete the "db.sqlite" file located in your fireshare appdata directory. Then start the container again. This will require that fireshare re-scans all your files. You will also lose all of your view counts on your files. Edited August 17, 20232 yr by Shane Israel
August 18, 20232 yr 18 hours ago, Shane Israel said: @Cheezelz Fireshare uses its database as the source of truth. So if you don't delete your files using fireshare it will think that the file is missing (i.e maybe a drive didn't mount, or it moved, etc, etc). So in your case to remedy the issue, you can do this in one of two ways currently. 1. On every file in Fireshare that says "File Missing" click the edit button (pencil icon) and choose "Delete". This will delete the file and all associated data (thumbnail, symlink, db entry). 2. If you have too many "Missing File" files that you don't want to have to manually delete using method 1, you can instead stop the fireshare container and then delete the "db.sqlite" file located in your fireshare appdata directory. Then start the container again. This will require that fireshare re-scans all your files. You will also lose all of your view counts on your files. Yeah that second option sounds great, thanks for the info!
November 8, 2025Nov 8 Been using this for awhile now and love it, but it seems at least for me the discord embeds are broken.
November 8, 2025Nov 8 Author 29 minutes ago, KLLSWITCH said:Been using this for awhile now and love it, but it seems at least for me the discord embeds are broken.Well seeing as I can't access your fireshare server, I would assume you have a whitelist in place. How are discords servers supposed to access your server to get the metadata needed to display embeds then?
November 8, 2025Nov 8 Author Actually I was able to connect but only through an insecure connection. So that's probably the issue. Discord embeds will only work if you have a valid https certificate in place. This is a requirement by Discord.
November 8, 2025Nov 8 Author If you need further validation that the issue is on your end. Copy a link from any video on my demo site and paste it into your discord and you'll see that it works and embeds. The demo site is always running the latest version of fireshare.https://v.fireshare.net
November 8, 2025Nov 8 1 hour ago, Shane Israel said:If you need further validation that the issue is on your end. Copy a link from any video on my demo site and paste it into your discord and you'll see that it works and embeds. The demo site is always running the latest version of fireshare.https://v.fireshare.netim guessing its something that NGINX is messing up then. Ill dig into it.Thank you for the quick replies!
February 21Feb 21 This container used to be awesome and worked great with my SWAG reverse proxy. For the past 4 months or so, I'm no longer able to access it correctly from the public URL. I get a red banner at the bottom that says "<html> <head> <title>Bad Request</title> </head> <body> <h1><p>Bad Request</p></h1> Contradictory scheme headers </body> </html>". When trying to login, it says "An unknown error occurred while trying to log in". AI keeps telling me it's something to do with X-Forwarders, but no matter what I try I cannot get it working properly. All my other services work fine with my SWAG container, and I've even fully reset and tried setting it up from scratch, but I get the same thing. Any ideas?
February 21Feb 21 Author 7 minutes ago, Kreeze said:This container used to be awesome and worked great with my SWAG reverse proxy. For the past 4 months or so, I'm no longer able to access it correctly from the public URL. I get a red banner at the bottom that says "<html> <head> <title>Bad Request</title> </head> <body> <h1><p>Bad Request</p></h1> Contradictory scheme headers </body> </html>". When trying to login, it says "An unknown error occurred while trying to log in". AI keeps telling me it's something to do with X-Forwarders, but no matter what I try I cannot get it working properly. All my other services work fine with my SWAG container, and I've even fully reset and tried setting it up from scratch, but I get the same thing. Any ideas?I'll be honest. I have no idea what a "SWAG" container is. What I can say, the core boot up of Fireshare has not changed. More than likely something in your setup has changed. I know nothing about SWAG containers or what that entails but to insinuate that it's a Fireshare issue and that something that isn't even listed anywhere in the Fireshare docs as "officially supported" suddenly isn't working right is not on me. Not sure what else to tell you. Those errors you are experiencing sound like CORS issues. Which could be caused by a number of things that I can't really help debug unless I was looking at your system directly. My demo site, https://v.fireshare.net is set up on Unraid no differently than explained in the docs with no fancy SWAG stuff and it works just fine and is always updated to use the latest nightly release. Edited February 21Feb 21 by Shane Israel
February 21Feb 21 24 minutes ago, Shane Israel said:I'll be honest. I have no idea what a "SWAG" container is. What I can say, the core boot up of Fireshare has not changed. More than likely something in your setup has changed. I know nothing about SWAG containers or what that entails but to insinuate that it's a Fireshare issue and that something that isn't even listed anywhere in the Fireshare docs as "officially supported" suddenly isn't working right is not on me. Not sure what else to tell you. Those errors you are experiencing sound like CORS issues. Which could be caused by a number of things that I can't really help debug unless I was looking at your system directly. My demo site, https://v.fireshare.net is set up on Unraid no differently than explained in the docs with no fancy SWAG stuff and it works just fine and is always updated to use the latest nightly release.SWAG (Secure Web Application Gateway) is just a pre-built nginx reverse proxy with certbot and fail2ban. It's how I securely host my internal resources publicly.
February 21Feb 21 Author My best guess is fail2ban is incorrectly set up or blocking fireshare. I would review you SWAG settings. But what I can say with 100% confidence is that the issue is not Fireshare. You may want to go request for help in the SWAG forums.
February 21Feb 21 Please do not be so quick to dismiss issues raised by users of your applications within Unraid. Using a reverse proxy to securely and publicly host HTTP web apps like yours is best practice for conserving public IP addresses. Even if you claim using something as basic as a reverse proxy is "not officially supported," these forum posts (that are linked directly from the Unraid Docker apps) are designed for the entire Unraid community to come together with solutions to issues; not just the app creators.I was finally able to get it working today after recreating my Fireshare configuration in my nginx reverse proxy proxy-confs. Gunicorn (the HTTP server used by Fireshare) does not like it when both X-Forwarded-Proto: https and the older X-Forwarded-Protocol headers are used simultaneously, as is the default for the SWAG reverse proxy container. Here is my working configuration for anyone running into this issue in the future:server { listen 443 ssl; listen [::]:443 ssl; server_name fireshare.*; index index.html; root /config/www; # Enable HSTS (optional but recommended once everything works) # add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; # all ssl-related config is in /config/nginx/ssl.conf which SWAG includes automatically # Security headers (optional, but good practice) add_header X-Frame-Options "SAMEORIGIN"; add_header X-Content-Type-Options "nosniff"; add_header X-XSS-Protection "1; mode=block"; location / { # IMPORTANT: Only set the one modern proto header to prevent "Contradictory scheme headers" proxy_set_header X-Forwarded-Proto $scheme; # Do NOT add X-Forwarded-Protocol or X-Forwarded-Ssl here proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # WebSocket support (Fireshare uses it for live preview/upload progress) proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; # Increase timeouts for large file uploads proxy_read_timeout 3600s; proxy_send_timeout 3600s; client_max_body_size 0; # unlimited upload size (or set to 10G etc.) proxy_pass http://10.0.1.101:8081; # ← change to your Unraid server's physical network IP and Fireshare port proxy_redirect off; }}
February 21Feb 21 Author @Kreeze I never said reverse proxies are not supported. I said that SWAG which sounds a lot more than a simple reverse proxy and more of a package of softwares working together. For refernce, the demo site is sitting behind NPM. To me, that is a whole recipe of stuff that could have been causing your problem depending on your configuration. Please do not be so quick to dismiss issues raised by users of your applications within Unraid.I don't know what you want me to do. I do not have access to your system and you provided me with zero logs. There's nothing that I could have supported you with, I could have spent hours trying to figure out why your "swag" isn't working and come up with absolutely nothing because I don't have your server in my hands to trial and error the issues. You told me this started happening months ago and you are THE ONLY person to report this issue. There are thousands of people using this app daily and if this was a Fireshare issue I would have seen tons of reports about it. That being said, I was not wrong when I said it wasn't a Fireshare issue.. As you were able to figure out, it was a config issue in your setup. I am perfectly happy with helping debug actual issue but when you don't give me anything to go off of other than "It used to work with SWAG but now it doesn't" and are upset when I tell you that I don't see how it could be a Fireshare issue and that it's likely something to do with your config, what exactly do you expect me to do? I'm not going to pull up a chair, install a SWAG container, spend hours configuring and testing Fireshare through it all to help the only person to report any sort of issue with it and having said it's been happening for months.
March 2Mar 2 Any idea why Fireshare would suddenly declare that my config file isn't valid, and quit shortly after starting? I haven't touched the config in ages, and I'd edited all the settings from the web GUI anyway. It even does this when I copy/paste a sample config directly from the GitHub wiki.
March 13Mar 13 On 2/21/2026 at 5:47 PM, Kreeze said:Please do not be so quick to dismiss issues raised by users of your applications within Unraid. Using a reverse proxy to securely and publicly host HTTP web apps like yours is best practice for conserving public IP addresses. Even if you claim using something as basic as a reverse proxy is "not officially supported," these forum posts (that are linked directly from the Unraid Docker apps) are designed for the entire Unraid community to come together with solutions to issues; not just the app creators.I was finally able to get it working today after recreating my Fireshare configuration in my nginx reverse proxy proxy-confs. Gunicorn (the HTTP server used by Fireshare) does not like it when both X-Forwarded-Proto: https and the older X-Forwarded-Protocol headers are used simultaneously, as is the default for the SWAG reverse proxy container. Here is my working configuration for anyone running into this issue in the future:server {listen 443 ssl;listen [::]:443 ssl;server_name fireshare.*;index index.html;root /config/www;# Enable HSTS (optional but recommended once everything works)# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;# all ssl-related config is in /config/nginx/ssl.conf which SWAG includes automatically# Security headers (optional, but good practice)add_header X-Frame-Options "SAMEORIGIN";add_header X-Content-Type-Options "nosniff";add_header X-XSS-Protection "1; mode=block";location / {# IMPORTANT: Only set the one modern proto header to prevent "Contradictory scheme headers"proxy_set_header X-Forwarded-Proto $scheme;# Do NOT add X-Forwarded-Protocol or X-Forwarded-Ssl hereproxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# WebSocket support (Fireshare uses it for live preview/upload progress)proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";# Increase timeouts for large file uploadsproxy_read_timeout 3600s;proxy_send_timeout 3600s;client_max_body_size 0; # unlimited upload size (or set to 10G etc.)proxy_pass http://10.0.1.101:8081; # ← change to your Unraid server's physical network IP and Fireshare portproxy_redirect off;}}Worked like a charm! Thanks.
March 24Mar 24 On 2/21/2026 at 5:47 PM, Kreeze said:Please do not be so quick to dismiss issues raised by users of your applications within Unraid. Using a reverse proxy to securely and publicly host HTTP web apps like yours is best practice for conserving public IP addresses. Even if you claim using something as basic as a reverse proxy is "not officially supported," these forum posts (that are linked directly from the Unraid Docker apps) are designed for the entire Unraid community to come together with solutions to issues; not just the app creators.I was finally able to get it working today after recreating my Fireshare configuration in my nginx reverse proxy proxy-confs. Gunicorn (the HTTP server used by Fireshare) does not like it when both X-Forwarded-Proto: https and the older X-Forwarded-Protocol headers are used simultaneously, as is the default for the SWAG reverse proxy container. Here is my working configuration for anyone running into this issue in the future:server {listen 443 ssl;listen [::]:443 ssl;server_name fireshare.*;index index.html;root /config/www;# Enable HSTS (optional but recommended once everything works)# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;# all ssl-related config is in /config/nginx/ssl.conf which SWAG includes automatically# Security headers (optional, but good practice)add_header X-Frame-Options "SAMEORIGIN";add_header X-Content-Type-Options "nosniff";add_header X-XSS-Protection "1; mode=block";location / {# IMPORTANT: Only set the one modern proto header to prevent "Contradictory scheme headers"proxy_set_header X-Forwarded-Proto $scheme;# Do NOT add X-Forwarded-Protocol or X-Forwarded-Ssl hereproxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# WebSocket support (Fireshare uses it for live preview/upload progress)proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";# Increase timeouts for large file uploadsproxy_read_timeout 3600s;proxy_send_timeout 3600s;client_max_body_size 0; # unlimited upload size (or set to 10G etc.)proxy_pass http://10.0.1.101:8081; # ← change to your Unraid server's physical network IP and Fireshare portproxy_redirect off;}}This is the way.@Kreeze - this worked a treat, many thanks for the SWAG fix. @Shane Israel - many thanks for the platform.🏆
April 30Apr 30 I am getting this error when trying to start the app on a fresh install:8080 was already used so I changed it but it is still occuring.Any suggestions? ThanksEDIT: Removing "--gpus=all" from extra parameters worked for me and it is now running. Edited April 30Apr 30 by Chimera17
May 1May 1 On 2/21/2026 at 6:47 PM, Kreeze said:Please do not be so quick to dismiss issues raised by users of your applications within Unraid. Using a reverse proxy to securely and publicly host HTTP web apps like yours is best practice for conserving public IP addresses. Even if you claim using something as basic as a reverse proxy is "not officially supported," these forum posts (that are linked directly from the Unraid Docker apps) are designed for the entire Unraid community to come together with solutions to issues; not just the app creators.I was finally able to get it working today after recreating my Fireshare configuration in my nginx reverse proxy proxy-confs. Gunicorn (the HTTP server used by Fireshare) does not like it when both X-Forwarded-Proto: https and the older X-Forwarded-Protocol headers are used simultaneously, as is the default for the SWAG reverse proxy container. Here is my working configuration for anyone running into this issue in the future:server {listen 443 ssl;listen [::]:443 ssl;server_name fireshare.*;index index.html;root /config/www;# Enable HSTS (optional but recommended once everything works)# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;# all ssl-related config is in /config/nginx/ssl.conf which SWAG includes automatically# Security headers (optional, but good practice)add_header X-Frame-Options "SAMEORIGIN";add_header X-Content-Type-Options "nosniff";add_header X-XSS-Protection "1; mode=block";location / {# IMPORTANT: Only set the one modern proto header to prevent "Contradictory scheme headers"proxy_set_header X-Forwarded-Proto $scheme;# Do NOT add X-Forwarded-Protocol or X-Forwarded-Ssl hereproxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# WebSocket support (Fireshare uses it for live preview/upload progress)proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";# Increase timeouts for large file uploadsproxy_read_timeout 3600s;proxy_send_timeout 3600s;client_max_body_size 0; # unlimited upload size (or set to 10G etc.)proxy_pass http://10.0.1.101:8081; # ← change to your Unraid server's physical network IP and Fireshare portproxy_redirect off;}}On 2/21/2026 at 6:47 PM, Kreeze said:Please do not be so quick to dismiss issues raised by users of your applications within Unraid. Using a reverse proxy to securely and publicly host HTTP web apps like yours is best practice for conserving public IP addresses. Even if you claim using something as basic as a reverse proxy is "not officially supported," these forum posts (that are linked directly from the Unraid Docker apps) are designed for the entire Unraid community to come together with solutions to issues; not just the app creators.I was finally able to get it working today after recreating my Fireshare configuration in my nginx reverse proxy proxy-confs. Gunicorn (the HTTP server used by Fireshare) does not like it when both X-Forwarded-Proto: https and the older X-Forwarded-Protocol headers are used simultaneously, as is the default for the SWAG reverse proxy container. Here is my working configuration for anyone running into this issue in the future:server {listen 443 ssl;listen [::]:443 ssl;server_name fireshare.*;index index.html;root /config/www;# Enable HSTS (optional but recommended once everything works)# add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;# all ssl-related config is in /config/nginx/ssl.conf which SWAG includes automatically# Security headers (optional, but good practice)add_header X-Frame-Options "SAMEORIGIN";add_header X-Content-Type-Options "nosniff";add_header X-XSS-Protection "1; mode=block";location / {# IMPORTANT: Only set the one modern proto header to prevent "Contradictory scheme headers"proxy_set_header X-Forwarded-Proto $scheme;# Do NOT add X-Forwarded-Protocol or X-Forwarded-Ssl hereproxy_set_header Host $host;proxy_set_header X-Real-IP $remote_addr;proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;# WebSocket support (Fireshare uses it for live preview/upload progress)proxy_set_header Upgrade $http_upgrade;proxy_set_header Connection "upgrade";# Increase timeouts for large file uploadsproxy_read_timeout 3600s;proxy_send_timeout 3600s;client_max_body_size 0; # unlimited upload size (or set to 10G etc.)proxy_pass http://10.0.1.101:8081; # ← change to your Unraid server's physical network IP and Fireshare portproxy_redirect off;}}I appreciate the config posted but I am having issues getting it to work, I only changed the IP at the bottom and saved it to cache => appdata =>swag =>nginx => proxy-confs but it still didn't seem to work. I am still unsure if I have SWAG properly setup. Can you run through the steps you went through to getting SWAG configured properly or maybe link a guide? Thanks.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.