Shane Israel

@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. 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.

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.

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 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.

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

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.

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?

@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.

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

@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.

@Neldonado I would do a reinstall of Fireshare completely then if the issue aligns back to when you had appdata issues. Delete both the data and processed folders. When you reinstall Fireshare your old links will still work so long as you do not edit the video files. You can rename the files or even move them to a different subfolder. Fireshare generates links based off the hash data of the file which will always be the same unless the file is changed. So you don't have to worry about your old links no longer working.

If the files were encoded in h265 you'll see this issue. Most browsers do not support h265 playback. If your are certain that is not the issue you can stop Fireshare and delete your Fireshare database then start Fireshare again. After the initial video scan completes see if the videos play.

@phreeq I have a fix for this in the latest develop image. It's not yet merged into the stable release as I haven't had a chance to personally test it yet but so far people have said it does work. Please try the following image and let me know if that resolves the problem. shaneisrael/fireshare:develop

Is this equation you have for SSD Life Used still correct for a 1 TB Samsung 970 Evo Plus with a TBW of 1200? *512/1000000000/600*100 I'm trying to figure out what each of the numbers are standing for or how I need to update that equation in the future if I get different SSD's with different TBW's. Confused on the Array Growth section. My assumption is that this number should always be increasing. I've been doing a ton of downloading the last couple days and at one point it was showing 1.1 TB of growth which made sense, but today its showing 648 GB like it went down but I haven't deleted anything?

I can not for the life of me get Telegraf to run. It just immediately dies and there's only one error in the logs which I can't figure out. As far as I can tell my config is fine. WARNING: apt does not have a stable CLI interface. Use with caution in scripts. WARNING: apt does not have a stable CLI interface. Use with caution in scripts. debconf: delaying package configuration, since apt-utils is not installed 2022-08-06T21:20:14Z I! Starting Telegraf 1.20.2 2022-08-06T21:20:14Z I! Using config file: /etc/telegraf/telegraf.conf 2022-08-06T21:20:14Z E! [telegraf] Error running agent: Error loading config file /etc/telegraf/telegraf.conf: plugin inputs.cpu: line 3218: configuration specified the fields ["core_tags"], but they weren't used invoke-rc.d: could not determine current runlevel invoke-rc.d: policy-rc.d denied execution of start. Setting up libexpat1:amd64 (2.2.6-2+deb10u4) ... Setting up mime-support (3.62) ... Setting up libmagic-mgc (1:5.35-4+deb10u2) ... Setting up psmisc (23.2-1+deb10u1) ... Setting up libgc1c2:amd64 (1:7.6.4-0.4) ... Setting up libmagic1:amd64 (1:5.35-4+deb10u2) ... Setting up liblzo2-2:amd64 (2.10-0.1) ... Setting up file (1:5.35-4+deb10u2) ... Setting up bzip2 (1.0.6-9.2~deb10u1) ... Setting up libpython2.7-minimal:amd64 (2.7.16-2+deb10u1) ... Setting up libntlm0:amd64 (1.5-1+deb10u1) ... Setting up libidn11:amd64 (1.33-2.2) ... Setting up xz-utils (5.2.4-1+deb10u1) ... update-alternatives: using /usr/bin/xz to provide /usr/bin/lzma (lzma) in auto mode Setting up libfribidi0:amd64 (1.0.5-3.1+deb10u1) ... Setting up mailutils-common (1:3.5-4) ... Setting up libltdl7:amd64 (2.4.6-9) ... Setting up libevent-2.1-6:amd64 (2.1.8-stable-4) ... Setting up sensible-utils (0.0.12) ... Setting up exim4-config (4.92-8+deb10u6) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline Adding system-user for exim (v4) Setting up guile-2.2-libs:amd64 (2.2.4+1-2+deb10u1) ... Setting up libkyotocabinet16v5:amd64 (1.2.76-4.2+b1) ... Setting up cron (3.0pl1-134+deb10u1) ... Adding group `crontab' (GID 102) ... Done. invoke-rc.d: could not determine current runlevel invoke-rc.d: policy-rc.d denied execution of start. Setting up libgsasl7 (1.8.0-8+deb10u1) ... Setting up libpython2.7-stdlib:amd64 (2.7.16-2+deb10u1) ... Setting up libunbound8:amd64 (1.9.0-2+deb10u2) ... Setting up libgnutls-dane0:amd64 (3.6.7-4+deb10u7) ... Setting up libpython2.7:amd64 (2.7.16-2+deb10u1) ... Setting up exim4-base (4.92-8+deb10u6) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline exim: DB upgrade, deleting hints-db Setting up exim4-daemon-light (4.92-8+deb10u6) ... debconf: unable to initialize frontend: Dialog debconf: (TERM is not set, so the dialog frontend is not usable.) debconf: falling back to frontend: Readline invoke-rc.d: could not determine current runlevel invoke-rc.d: policy-rc.d denied execution of start. Initializing GnuTLS DH parameter file Setting up libmailutils5:amd64 (1:3.5-4) ... Setting up mailutils (1:3.5-4) ... update-alternatives: using /usr/bin/frm.mailutils to provide /usr/bin/frm (frm) in auto mode update-alternatives: using /usr/bin/from.mailutils to provide /usr/bin/from (from) in auto mode update-alternatives: using /usr/bin/messages.mailutils to provide /usr/bin/messages (messages) in auto mode update-alternatives: using /usr/bin/movemail.mailutils to provide /usr/bin/movemail (movemail) in auto mode update-alternatives: using /usr/bin/readmsg.mailutils to provide /usr/bin/readmsg (readmsg) in auto mode update-alternatives: using /usr/bin/dotlock.mailutils to provide /usr/bin/dotlock (dotlock) in auto mode update-alternatives: using /usr/bin/mail.mailutils to provide /usr/bin/mailx (mailx) in auto mode Processing triggers for libc-bin (2.28-10) ... Reading package lists... Building dependency tree... Reading state information... lm-sensors is already the newest version (1:3.5.0-3). 0 upgraded, 0 newly installed, 0 to remove and 28 not upgraded. Reading package lists... Building dependency tree... Reading state information... The following NEW packages will be installed: nvme-cli 0 upgraded, 1 newly installed, 0 to remove and 28 not upgraded. Need to get 247 kB of archives. After this operation, 570 kB of additional disk space will be used. Get:1 http://deb.debian.org/debian buster/main amd64 nvme-cli amd64 1.7-1 [247 kB] Fetched 247 kB in 0s (3198 kB/s) Selecting previously unselected package nvme-cli. (Reading database ... 11897 files and directories currently installed.) Preparing to unpack .../nvme-cli_1.7-1_amd64.deb ... Unpacking nvme-cli (1.7-1) ... Setting up nvme-cli (1.7-1) ... On top of that, I can't get the Grafana container to run at all either. It's giving me permission denied errors. mkdir: can't create directory '/var/lib/grafana/plugins': Permission denied mkdir: can't create directory '/var/lib/grafana/plugins': Permission denied GF_PATHS_DATA='/var/lib/grafana' is not writable. You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migrate-to-v51-or-later GF_PATHS_DATA='/var/lib/grafana' is not writable. You may have issues with file permissions, more information here: http://docs.grafana.org/installation/docker/#migrate-to-v51-or-later This is the first time I've ever installed Grafana so it shouldn't be a migration issue. Any help would be much appreciated. Thanks! EDIT ------------------------------- Okay so I managed to figure out a fix for both of these. For Telegraf I had to comment out the "core_tags = false" setting of the [[inputs.cpu]] section. Maybe this is because I'm on a Ryzen cpu? For Grafana I had to add an extra parameter. --user="$UID:$GID" Everything seems to be working fine now except that the Docker icons in Grafana do not show up. I'm thinking its an issue with Unraid API not downloading the images? Do I need to set up some MQTT thing? EDIT2 Figured out the Docker icons issue. Instead of using my local ip address for the Unraid API I set up the server using the hashed address provided by Unraid and that seemed to solve that problem.

@colev14 I was the one replying to you on reddit. You'll probably need to request help from somebody who has experience with unraid folder permission issues. I would try posting in the General Support asking for help debugging file/folder permissions of your /mnt/user/appdata/fireshare and /mnt/user/appdata/fireshare_processed folders.