plantsandbinary

With the cloudfare-ddns container, is it possible to add another totally different domain? like: mysite.com anothersite.net How do I do this in the container settings?

For anyone who needs it. Here's how I fixed the matrix/element containers for the 4th time... it really needs some tweaking. At least the container here should generate the config itself, so I don't have to port it from the official container image. There is something wrong with how this container tries to generate the config. Basically it expects a config first or doesn't have the permissions to make one.

After trying to get this terror of a service up and running again (after having spent hours some months ago and losing my docker backup), I managed to do it again. I've done all the hard work of downloading the OFFICIAL docker container of this and then generating the updated config files. You need the following, minimum to proceed. matrix_files.zip Follow the instructions in the readme.txt Make sure to make the /appdata/matrix folder yourself via samba and copy the files over, or at least ensure that the permissions are correct. The container doesn't really have proper permissions set so it often cannot access files. Especially if you made them eg. via terminal as root. Now remember to add the registration_shared_secret variable to your homeserver.yaml like so, it's around line 1300: registration_shared_secret: "s0mekind0fmassive:::9generatedSTRINGhere!!" Now you can install the matrix container from the Apps tab in Unraid. After which you can register an admin user so you can actually make changes. Then you can remove the shared registration token. $ register_new_matrix_user -c /data/homeserver.yaml http://0.0.0.0:8008 New user localpart [matrix]: <youradminusername> Password: Confirm password: Make admin [no]: yes Sending registration request... Success! $ Now you can register accounts and such using the OTHER app element-web. God that was a pain... now it's 6:45am and I am going to sleep.

I managed to fix it by signing up for the "my servers" thing, but it would be nice to not have to do that... at least its still in beta and I shouldn't have had to connect my machine in order to see the option to replace the key. So I would say that surely it is a bug.

I've never changed USB or replaced my USB. So I thought have my "yearly" replacement available. I did the full backup as told on the Wiki, used the USB creator to make a new USB using the backup.zip and after booting my setup. I only have the following options:

I have 27,937 photos in Photoprism. With a total size of: My appdata/photoprism/cache/... directory has the following stats: Why on earth is just the tumbnail cache taking so much storage? It's eating 60GB of my SSD cache drive. On top of this, photoprism eats 95% of my 4 core 8 thread CPU when doing indexing and there is no progress bar or ETA to display during the indexing process. I haven't set any different settings or anything. Just ran the container and set my library location. Surely there is something wrong with needing 185,400 thumbnail cache files spread through 8,500 folders.

Why does this container need to be installed in "host" mode and not on my custom network? If I install it on eg. "Web" custom network which I use to port forward and proxy everything for outside use. I don't get a WEBUI and I also get these errors in the log: 2022-04-23 15:47:23,155 DEBG 'plexmediaserver' stderr output: Error in command line:the argument for option '--serverUuid' should follow immediately after the equal sign Crash Uploader options (all are required): --directory arg Directory to scan for crash reports --serverUuid arg UUID of the server that crashed --userId arg User that owns this product --platform arg 2022-04-23 15:47:23,156 DEBG 'plexmediaserver' stderr output: Platform string --platformVersion arg Platform version string --vendor arg Vendor string --device arg Device string --model arg Device model string --sentryUrl arg Sentry URL to upload to --sentryKey arg Sentry Key for the project --version arg Version of the product --allowRetries arg Whether we will allow retries 2022-04-23 15:47:39,878 DEBG 'plexmediaserver' stdout output: Critical: libusb_init failed Installing it in Host mode works perfectly.

Figured it out I think. I have HSTS enabled on Cloudfare. So I was passing proxy http and http port to Nginx which was trying to redirect from http to https (which used to be my setting in Cloudfare). This was giving instant 403 error because after enabling HSTS support, only https requests are parsed and no transport upgrade happens. Proxied https to https port in Heimdall and voilá, it works fine. I get the basic auth popup and failure to enter gives 401 error. Putting it in correctly gives a proper page load. Looks like this now: https > to https port

Why isn't the nginx_basic_auth pop-up working on my device? I had to re-install this container and for some reason it's no longer working. Here's my access list settings: When I attempt to go to the proxied URL eg. https://mysite.com I just get this error: I never get the browser popup asking me to authenticate like I used to. What am I doing wrong here?

Some other odd things I noticed. The initial amount of damaged files was over 120,000 with more than 62,000 folders. However after rebooting. I only had about 12,000 files and 600 folders in the lost+found directory. After stopping the array and starting it again, this number dropped down to about 8000 and 515. So presumably every time the array is mounted, it does some sort of check to see if it can restore orphaned files and folders to their original locations? That was about as far as I got though with that. However, it did make things much easier to recover from. I used XYPlorer to show the folder sizes, culled any that were empty or under a certain size. Also I used it to cull any files which were under at least 100KB. This left me with about 2000 files and about 250 folders to go through. Then it was just a process of using XYPlorer to show only eg. "Image Files" or "Music Files" or "Documents" and move them accordingly their proper locations. It helped to have my folder structured like this and keep things mostly totally organized over the years: //TOWER/tank/Backups/<OS_type> //TOWER/tank/Files/ //TOWER/tank/Files/Media/ (Documents, Downloads, Photos, Music etc) > Photos/2003, 2004, 2005, et cetera. //TOWER/tank/Files/torrents/<tracker_name> //TOWER/tank/Files/Work/>company_name>/repos Because everything was tightly organized, I managed to restore a lot of it without too much trouble. At least the stuff I cared about. Maybe I lost about 5% in the end. I can say that UNRAID probably had something to do with removing a lot of the files out of lost+found and putting them back too upon mounting.

Thanks to how I structured my file/folder tree I found that using find | less and scrolling through the results, I was able to find out the following based on the fact that the highest level folder names were missing but enough information was left in their subfolders by way of folder names and filenames and their extensions. This left me with the following: ./669603920 ^^^ This is the //TOWER/tank/Files/Backup folder There should be Documents, Media, Downloads, Videos, Music, eBooks etc. in there >> Move everything from this location back to the surviving folder on the machine ./2147483779 ^^^ This is the //TOWER/tank/torrents folder >> Move everything from this location back to the surviving folder on the machine ./2169315211/ ^^^ More photos not sure what (possibly some unsorted backup) but there's a lot /656130169/ ^^^ Not sure what this is? Check it out. It has interesting stuff in it. ./2147483875 ^^^ This is possibly //TOWER/tank/work/employername folder ./2155167598/ ^^^ Some previous unsorted phone backup. ./2222606136 ^^^ Girlfriend's artworks ./2224369673 ^^^ More important stuff ./2530965706 ^^^ GIrlfriend's design stuff ./2673591577 ^^^ Another unsorted phone Backup ./4511549153 ^^^ Former Windows 10 & 11 Backup The other hundred thousand-something folders seem to be 90% git repos which I cloned for work or hobby purposes. As some of these repos contained tens of thousands of files. This is most likely what makes up the bulk of lost+found. I'm now going to mount the drives. Pay most attention to moving everything out of the above folders. Then dump the drives in the cupboard after I've had enough and revisit this issue in days, months, decades when I feel like going through them again. One final thing that also helped was using the flat view in 7zip (free) or even better "Branch View" in XYPlorer. This let me find all the PNG, JPG, etc. files in ALL of the folders which were spread thin, so I could then view them as a list, sort them by "type" and grab them all and move them into one folder. I then re-organized these by "date created" which is how they were done before. Lesson learned. Always have a backup... of the backup.

Hi, I'm making a new thread (hope this is okay) after suffering metadata loss in my other thread here: What I've been able to do so far: Figure out what degree of data was orphaned per drive. //TOWER/lost+found/ Disk 1 - WDC_WD40EFRX-68N32N0_WD-WCC7K5CCCED9 - 4 TB (sde) 1772 objects: 1014 directories, 758 files (64.8 GB total) Disk 2 - WDC_WD40EFRX-68N32N0_WD-WCC7K5CCCED9 - 4 TB (sde) 6419 objects: 550 directories, 5869 files (17.4 GB total) Disk 3 - TOSHIBA_DT01ACA300_14SRJ24GS - 3 TB (sdc) 4163 objects: 3170 directories, 993 files (84.6 GB total) root@Tower:/mnt/user/lost+found# files * cryptobin.co/r1k6s5y5 password: unraid The majority of damaged data seems to be JPG, PNG, HTML and FLAC files as shown in the crypobin link above. I found this post: https://techcult.com/how-to-restore-files-from-lostfound/ Which contains a script at the bottom which I will put here (had to edit slightly to fix bad syntax): #!/bin/bash fsck -y /dev/sdc1 mkdir /tmp/recover mount /dev/sdc1 /tmp/recover -o rw cd /tmp/recover/lost+found ( echo 'set -v' file * | grep directory 2>/dev/null | perl -pe 's/^(\#[0-9]+)\:.*$/ls -l '"'"'$1'"'"'/' ) | sh > /tmp/listing I was wondering does this have some chance of working for me? What exactly does it do? It looks to append file extensions to the files using their headers via the 'file' command? Or am I wrong about this? EDIT: Couldn't get the script to work. I don't think it's written properly.

Ok thank you so much for the help. Big lessons learned today. I'll give this and a few more things a try and see how it goes. Failing that, maybe I'll send the disks to a data recovery company. It's my entire childhood so money isn't really a factor here. All the data seems to be there but just without its original folder tree structure, metadata and file extensions. Failing that, I'll store the disks away for a few years and who knows maybe 10-30 years from now technology will advance far enough that AI or something will be able to dig through all this and repair it all for me. 😂 I've bought 5 new drives to start over. So one way or another these ones are done for using. I won't risk the data getting more damaged than it already has been.

No this was it. I've been using UNRAID now for years. My understanding was that I would need 2 drive failures (and one would have to be parity) to lose anything. So short of a lightning strike or super bad luck with 2 simultaneous drive failures. I'd be able to recover the data. In this case I lost all the metadata and now I just have 120k files and 62k folders just sitting in lost+found which I have no idea what to do with. I'm grateful for the help thus far, but everything shows that my hardware is fine, and I only ever experienced problems after updating. It's my own fault for not having another backup but I was suggested to update to solve a security issue I found during login. This was the result. So naturally I am feeling super bitter about this. I carried a lot of this stuff through CDs in 2003 onward. This is 18 years worth of stuff smashed and the damage extends through everything I have. How could kernel issues cause so many inode issues? Is there any way I can restore the metadata? Surely someone else has been in a similar situation, even to a lesser extent. Is there some utility I can use on these xfs drives? Also, is there a more redundant way I can set this up in the future using UNRAID of course excepting having another backup of all of my data (because I will obviously do that). Maybe use zfs or btrfs or something instead?

Don't the diagnostics show anything? No one has commented on any of them.

How could bad RAM destroy the metadata for everything across 4 disks? I'm just trying to make sense of this. I have certified HP ECC memory too. I realise things break at times but this was supposed to be 'the backup'. @itimpi how do I do that? Sorry my head is swimming.

Looks like my docker didn't backup properly either for some reason. So I've lost everything there too... Some of this data loss dates back to 2003 when I was just a kid, and I carried this stuff across like 15 computers and probably more than 30 USB drives.

Ok so... I've run xfs_repair -vL /dev/md1, 2, 3, etc. Rebooted the machine. I'm up and running again and the disks are mounted. Got myself a lost+found share with wait for it.... with no extensions or other metadata information. So it seems I've lost roughly 80% of all of my data... I guess it's been moved into the lost+found share. Almost all of the stuff I lost are irreplaceable personal files. Photos, videos, writings etc. I've also lost scans of old important documents. This is the worst data loss I've ever suffered. I don't understand how this happened. All from updating the OS? I had no Docker issues. No problem with my cache drive. Did not change any docker containers. No VMs running. How did this happen? Isn't the whole point of the parity drive that I am supposed to be able to recover my data? Unless both the parity AND another drive both fail at the same time. Please someone, help me understand... Is it possible to rebuild everything from lost+found? I just have a bunch of 3436, 6457472, 75683784 etc. files which I have no idea what they are but some are huge and some are tiny. @JorgeB

Ran a check first, jeez. What happened? Last check completed on Thursday, 14 April 2022, 22:26 (today) Duration: 8 hours, 12 minutes, 13 seconds. Average speed: 135.5 MB/s Finding 46789 errors If I've ever had a dirty shutdown or something I've only seen like 4-6 errors max, but near to 47,000??? Here's the full diagnostics. I cannot get these to mount no matter what and nothing should have touched them. I just swapped out the cache drive, that's it. tower-diagnostics-20220414-2320.zip

Downgraded and also replaced the drive with a spare. Still getting this error "Unmountable" I haven't changed the filesystem or anything on the single parity and 3 array drives. What am I supposed to do now? @JorgeB

Roger that.

Sorry for all the posts, frantically trying to fix things. Seems I need to remove the intel_iommu=on from the Linux kernel boot parameters. Due to this issue: https://support.hpe.com/hpesc/public/docDisplay?docId=emr_na-c04565693

So how can I fix the filesystem problem? I just zeroed the entire cache drive. Reformatted it as xfs and now I get this: Phase 1 - find and verify superblock... bad primary superblock - bad magic number !!! attempting to find secondary superblock... It never found the secondary superblock. I've no idea how I could have a filesystem problem unless this happened after upgrading to 6.10.0-rc4 because that's the only thing I did recently. My system is an HP ProLaiant Microserver Gen8. Running the last BIOS they released for it. My syslog is getting polluted with these errors too. Never seen them before: Apr 14 11:01:34 Tower kernel: DMAR: ERROR: DMA PTE for vPFN 0xaf83a already set (to af83a003 not 101a6b803) Apr 14 11:01:34 Tower kernel: ------------[ cut here ]------------ Apr 14 11:01:34 Tower kernel: WARNING: CPU: 6 PID: 3903 at drivers/iommu/intel/iommu.c:2387 __domain_mapping+0x2e5/0x390 Apr 14 11:01:34 Tower kernel: Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vhost_net tun vhost vhost_iotlb tap xfs md_mod ip6table_filter ip6_tables iptable_filter ip_tables x_tables bonding tg3 ipmi_ssif x86_pkg_temp_thermal intel_powerclamp i2c_core coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd rapl intel_cstate intel_uncore acpi_ipmi ahci libahci ipmi_si thermal acpi_power_meter button [last unloaded: tg3] Apr 14 11:01:34 Tower kernel: CPU: 6 PID: 3903 Comm: unraidd1 Tainted: G W I 5.15.30-Unraid #1 Apr 14 11:01:34 Tower kernel: Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 04/04/2019 Apr 14 11:01:34 Tower kernel: RIP: 0010:__domain_mapping+0x2e5/0x390 Apr 14 11:01:34 Tower kernel: Code: 2b 48 8b 4c 24 08 48 89 c2 4c 89 e6 48 c7 c7 8f c7 ef 81 e8 48 96 2c 00 8b 05 05 38 c3 00 85 c0 74 08 ff c8 89 05 f9 37 c3 00 <0f> 0b 8b 74 24 38 b8 34 00 00 00 8d 0c f6 83 e9 09 39 c1 0f 4f c8 Apr 14 11:01:34 Tower kernel: RSP: 0018:ffffc9000377f788 EFLAGS: 00010046 Apr 14 11:01:34 Tower kernel: RAX: 0000000000000000 RBX: ffff8881076371d0 RCX: 0000000000000027 Apr 14 11:01:34 Tower kernel: RDX: 0000000000000000 RSI: ffffc9000377f618 RDI: ffff888436f9c550 Apr 14 11:01:34 Tower kernel: RBP: ffff888107420000 R08: ffff888447f65a58 R09: 0000000000000000 Apr 14 11:01:34 Tower kernel: R10: 2933303862366131 R11: 366131303120746f R12: 00000000000af83a Apr 14 11:01:34 Tower kernel: R13: ffff8881076371d0 R14: 0000000000001000 R15: 00000000af83a000 Apr 14 11:01:34 Tower kernel: FS: 0000000000000000(0000) GS:ffff888436f80000(0000) knlGS:0000000000000000 Apr 14 11:01:34 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 14 11:01:34 Tower kernel: CR2: 00001513000281c0 CR3: 0000000108726006 CR4: 00000000000606e0 Apr 14 11:01:34 Tower kernel: Call Trace: Apr 14 11:01:34 Tower kernel: <TASK> Apr 14 11:01:34 Tower kernel: ? mempool_alloc+0x68/0x14f Apr 14 11:01:34 Tower kernel: intel_iommu_map_pages+0xf3/0x102 Apr 14 11:01:34 Tower kernel: __iommu_map+0x138/0x211 Apr 14 11:01:34 Tower kernel: __iommu_map_sg+0x8c/0x110 Apr 14 11:01:34 Tower kernel: iommu_dma_map_sg+0x245/0x3e3 Apr 14 11:01:34 Tower kernel: __dma_map_sg_attrs+0x63/0x95 Apr 14 11:01:34 Tower kernel: dma_map_sg_attrs+0xa/0x12 Apr 14 11:01:34 Tower kernel: ata_qc_issue+0xec/0x1ab Apr 14 11:01:34 Tower kernel: __ata_scsi_queuecmd+0x1f2/0x1fd Apr 14 11:01:34 Tower kernel: ata_scsi_queuecmd+0x41/0x7a Apr 14 11:01:34 Tower kernel: scsi_queue_rq+0x57d/0x6db Apr 14 11:01:34 Tower kernel: blk_mq_dispatch_rq_list+0x2a7/0x4da Apr 14 11:01:34 Tower kernel: __blk_mq_do_dispatch_sched+0x23d/0x281 Apr 14 11:01:34 Tower kernel: ? update_cfs_rq_load_avg+0x138/0x146 Apr 14 11:01:34 Tower kernel: __blk_mq_sched_dispatch_requests+0xd5/0x129 Apr 14 11:01:34 Tower kernel: blk_mq_sched_dispatch_requests+0x2f/0x52 Apr 14 11:01:34 Tower kernel: __blk_mq_run_hw_queue+0x50/0x76 Apr 14 11:01:34 Tower kernel: __blk_mq_delay_run_hw_queue+0x4d/0x108 Apr 14 11:01:34 Tower kernel: blk_mq_sched_insert_requests+0xa2/0xd9 Apr 14 11:01:34 Tower kernel: blk_mq_flush_plug_list+0xfb/0x12c Apr 14 11:01:34 Tower kernel: blk_mq_submit_bio+0x2e6/0x406 Apr 14 11:01:34 Tower kernel: submit_bio_noacct+0x9d/0x203 Apr 14 11:01:34 Tower kernel: ? raid5_generate_d+0xce/0x105 [md_mod] Apr 14 11:01:34 Tower kernel: unraidd+0x11a5/0x1237 [md_mod] Apr 14 11:01:34 Tower kernel: ? md_thread+0x103/0x12a [md_mod] Apr 14 11:01:34 Tower kernel: ? rmw5_write_data+0x17d/0x17d [md_mod] Apr 14 11:01:34 Tower kernel: md_thread+0x103/0x12a [md_mod] Apr 14 11:01:34 Tower kernel: ? init_wait_entry+0x29/0x29 Apr 14 11:01:34 Tower kernel: ? md_seq_show+0x6c8/0x6c8 [md_mod] Apr 14 11:01:34 Tower kernel: kthread+0xde/0xe3 Apr 14 11:01:34 Tower kernel: ? set_kthread_struct+0x32/0x32 Apr 14 11:01:34 Tower kernel: ret_from_fork+0x22/0x30 Apr 14 11:01:34 Tower kernel: </TASK> Apr 14 11:01:34 Tower kernel: ---[ end trace 7069ea449eb4fd61 ]--- Apr 14 11:01:34 Tower kernel: DMAR: ERROR: DMA PTE for vPFN 0xaf83b already set (to af83b003 not 14c18f803) Apr 14 11:01:34 Tower kernel: ------------[ cut here ]------------ Apr 14 11:01:34 Tower kernel: WARNING: CPU: 6 PID: 3903 at drivers/iommu/intel/iommu.c:2387 __domain_mapping+0x2e5/0x390 Apr 14 11:01:34 Tower kernel: Modules linked in: xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vhost_net tun vhost vhost_iotlb tap xfs md_mod ip6table_filter ip6_tables iptable_filter ip_tables x_tables bonding tg3 ipmi_ssif x86_pkg_temp_thermal intel_powerclamp i2c_core coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel aesni_intel crypto_simd cryptd rapl intel_cstate intel_uncore acpi_ipmi ahci libahci ipmi_si thermal acpi_power_meter button [last unloaded: tg3] Apr 14 11:01:34 Tower kernel: CPU: 6 PID: 3903 Comm: unraidd1 Tainted: G W I 5.15.30-Unraid #1 Apr 14 11:01:34 Tower kernel: Hardware name: HP ProLiant MicroServer Gen8, BIOS J06 04/04/2019 Apr 14 11:01:34 Tower kernel: RIP: 0010:__domain_mapping+0x2e5/0x390 Apr 14 11:01:34 Tower kernel: Code: 2b 48 8b 4c 24 08 48 89 c2 4c 89 e6 48 c7 c7 8f c7 ef 81 e8 48 96 2c 00 8b 05 05 38 c3 00 85 c0 74 08 ff c8 89 05 f9 37 c3 00 <0f> 0b 8b 74 24 38 b8 34 00 00 00 8d 0c f6 83 e9 09 39 c1 0f 4f c8 Apr 14 11:01:34 Tower kernel: RSP: 0018:ffffc9000377f788 EFLAGS: 00010046 Apr 14 11:01:34 Tower kernel: RAX: 0000000000000000 RBX: ffff8881076371d8 RCX: 0000000000000027 Apr 14 11:01:34 Tower kernel: RDX: 0000000000000000 RSI: ffffc9000377f618 RDI: ffff888436f9c550 Apr 14 11:01:34 Tower kernel: RBP: ffff888107420000 R08: ffff888447f65f50 R09: 0000000000000000 Apr 14 11:01:34 Tower kernel: R10: 2933303866383163 R11: 383163343120746f R12: 00000000000af83b Apr 14 11:01:34 Tower kernel: R13: ffff8881076371d8 R14: 0000000000001000 R15: 00000000af83b000 Apr 14 11:01:34 Tower kernel: FS: 0000000000000000(0000) GS:ffff888436f80000(0000) knlGS:0000000000000000 Apr 14 11:01:34 Tower kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 14 11:01:34 Tower kernel: CR2: 00001513000281c0 CR3: 0000000108726006 CR4: 00000000000606e0 Apr 14 11:01:34 Tower kernel: Call Trace: Apr 14 11:01:34 Tower kernel: <TASK> Apr 14 11:01:34 Tower kernel: ? mempool_alloc+0x68/0x14f Apr 14 11:01:34 Tower kernel: intel_iommu_map_pages+0xf3/0x102 Apr 14 11:01:34 Tower kernel: __iommu_map+0x138/0x211 Apr 14 11:01:34 Tower kernel: __iommu_map_sg+0x8c/0x110 Apr 14 11:01:34 Tower kernel: iommu_dma_map_sg+0x245/0x3e3 Apr 14 11:01:34 Tower kernel: __dma_map_sg_attrs+0x63/0x95 Apr 14 11:01:34 Tower kernel: dma_map_sg_attrs+0xa/0x12 Apr 14 11:01:34 Tower kernel: ata_qc_issue+0xec/0x1ab Apr 14 11:01:34 Tower kernel: __ata_scsi_queuecmd+0x1f2/0x1fd Apr 14 11:01:34 Tower kernel: ata_scsi_queuecmd+0x41/0x7a Apr 14 11:01:34 Tower kernel: scsi_queue_rq+0x57d/0x6db Apr 14 11:01:34 Tower kernel: blk_mq_dispatch_rq_list+0x2a7/0x4da Apr 14 11:01:34 Tower kernel: __blk_mq_do_dispatch_sched+0x23d/0x281 Apr 14 11:01:34 Tower kernel: ? update_cfs_rq_load_avg+0x138/0x146 Apr 14 11:01:34 Tower kernel: __blk_mq_sched_dispatch_requests+0xd5/0x129 Apr 14 11:01:34 Tower kernel: blk_mq_sched_dispatch_requests+0x2f/0x52 Apr 14 11:01:34 Tower kernel: __blk_mq_run_hw_queue+0x50/0x76 Apr 14 11:01:34 Tower kernel: __blk_mq_delay_run_hw_queue+0x4d/0x108 Apr 14 11:01:34 Tower kernel: blk_mq_sched_insert_requests+0xa2/0xd9 Apr 14 11:01:34 Tower kernel: blk_mq_flush_plug_list+0xfb/0x12c Apr 14 11:01:34 Tower kernel: blk_mq_submit_bio+0x2e6/0x406 Apr 14 11:01:34 Tower kernel: submit_bio_noacct+0x9d/0x203 Apr 14 11:01:34 Tower kernel: ? raid5_generate_d+0xce/0x105 [md_mod] Apr 14 11:01:34 Tower kernel: unraidd+0x11a5/0x1237 [md_mod] Apr 14 11:01:34 Tower kernel: ? md_thread+0x103/0x12a [md_mod] Apr 14 11:01:34 Tower kernel: ? rmw5_write_data+0x17d/0x17d [md_mod] Apr 14 11:01:34 Tower kernel: md_thread+0x103/0x12a [md_mod] Apr 14 11:01:34 Tower kernel: ? init_wait_entry+0x29/0x29 Apr 14 11:01:34 Tower kernel: ? md_seq_show+0x6c8/0x6c8 [md_mod] Apr 14 11:01:34 Tower kernel: kthread+0xde/0xe3 Apr 14 11:01:34 Tower kernel: ? set_kthread_struct+0x32/0x32 Apr 14 11:01:34 Tower kernel: ret_from_fork+0x22/0x30 Apr 14 11:01:34 Tower kernel: </TASK> Apr 14 11:01:34 Tower kernel: ---[ end trace 7069ea449eb4fd62 ]--- Apr 14 11:01:34 Tower kernel: DMAR: ERROR: DMA PTE for vPFN 0xaf83c already set (to af83c003 not 103e3c803)

That many LBAs = 56.40 TB of data written. It's 3.5 years old also. So I'd say it's finally kicked the bucket. Samsung states the 850 EVO should last 5 years or to 75TB TBW. So it's more than 2/3rd of the way there.

Safe to say it's dead jim? Here's the SMART data: smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.30-Unraid] (local build) Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org === START OF INFORMATION SECTION === Model Family: Samsung based SSDs Device Model: Samsung SSD 850 EVO 250GB Serial Number: S3R0NF0J888231T LU WWN Device Id: 5 002538 d422b6b74 Firmware Version: EMT03B6Q User Capacity: 250,059,350,016 bytes [250 GB] Sector Size: 512 bytes logical/physical Rotation Rate: Solid State Device Form Factor: 2.5 inches TRIM Command: Available Device is: In smartctl database [for details use: -P show] ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c SATA Version is: SATA 3.1, 6.0 Gb/s (current: 3.0 Gb/s) Local Time is: Thu Apr 14 11:30:52 2022 EEST SMART support is: Available - device has SMART capability. SMART support is: Enabled AAM feature is: Unavailable APM feature is: Unavailable Rd look-ahead is: Enabled Write cache is: Enabled DSN feature is: Unavailable ATA Security is: Disabled, NOT FROZEN [SEC1] Wt Cache Reorder: Enabled === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED General SMART Values: Offline data collection status: (0x00) Offline data collection activity was never started. Auto Offline Data Collection: Disabled. Self-test execution status: ( 0) The previous self-test routine completed without error or no self-test has ever been run. Total time to complete Offline data collection: ( 0) seconds. Offline data collection capabilities: (0x53) SMART execute Offline immediate. Auto Offline data collection on/off support. Suspend Offline collection upon new command. No Offline surface scan supported. Self-test supported. No Conveyance Self-test supported. Selective Self-test supported. SMART capabilities: (0x0003) Saves SMART data before entering power-saving mode. Supports SMART auto save timer. Error logging capability: (0x01) Error logging supported. General Purpose Logging supported. Short self-test routine recommended polling time: ( 2) minutes. Extended self-test routine recommended polling time: ( 133) minutes. SCT capabilities: (0x003d) SCT Status supported. SCT Error Recovery Control supported. SCT Feature Control supported. SCT Data Table supported. SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAGS VALUE WORST THRESH FAIL RAW_VALUE 5 Reallocated_Sector_Ct PO--CK 100 100 010 - 0 9 Power_On_Hours -O--CK 093 093 000 - 30832 12 Power_Cycle_Count -O--CK 099 099 000 - 72 177 Wear_Leveling_Count PO--C- 082 082 000 - 374 179 Used_Rsvd_Blk_Cnt_Tot PO--C- 100 100 010 - 0 181 Program_Fail_Cnt_Total -O--CK 100 100 010 - 0 182 Erase_Fail_Count_Total -O--CK 100 100 010 - 0 183 Runtime_Bad_Block PO--C- 100 100 010 - 0 187 Uncorrectable_Error_Cnt -O--CK 100 100 000 - 0 190 Airflow_Temperature_Cel -O--CK 070 051 000 - 30 195 ECC_Error_Rate -O-RC- 200 200 000 - 0 199 CRC_Error_Count -OSRCK 100 100 000 - 0 235 POR_Recovery_Count -O--C- 099 099 000 - 7 241 Total_LBAs_Written -O--CK 099 099 000 - 121124616664 ||||||_ K auto-keep |||||__ C event count ||||___ R error rate |||____ S speed/performance ||_____ O updated online |______ P prefailure warning General Purpose Log Directory Version 1 SMART Log Directory Version 1 [multi-sector log support] Address Access R/W Size Description 0x00 GPL,SL R/O 1 Log Directory 0x01 SL R/O 1 Summary SMART error log 0x02 SL R/O 1 Comprehensive SMART error log 0x03 GPL R/O 1 Ext. Comprehensive SMART error log 0x06 SL R/O 1 SMART self-test log 0x07 GPL R/O 1 Extended self-test log 0x09 SL R/W 1 Selective self-test log 0x10 GPL R/O 1 NCQ Command Error log 0x11 GPL R/O 1 SATA Phy Event Counters log 0x13 GPL R/O 1 SATA NCQ Send and Receive log 0x30 GPL,SL R/O 9 IDENTIFY DEVICE data log 0x80-0x9f GPL,SL R/W 16 Host vendor specific log 0xa1 SL VS 16 Device vendor specific log 0xa5 SL VS 16 Device vendor specific log 0xce SL VS 16 Device vendor specific log 0xe0 GPL,SL R/W 1 SCT Command/Status 0xe1 GPL,SL R/W 1 SCT Data Transfer SMART Extended Comprehensive Error Log Version: 1 (1 sectors) No Errors Logged SMART Extended Self-test Log Version: 1 (1 sectors) No self-tests have been logged. [To run self-tests, use: smartctl -t] SMART Selective self-test log data structure revision number 1 SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS 1 0 0 Not_testing 2 0 0 Not_testing 3 0 0 Not_testing 4 0 0 Not_testing 5 0 0 Not_testing 255 0 65535 Read_scanning was never started Selective self-test flags (0x0): After scanning selected spans, do NOT read-scan remainder of disk. If Selective self-test is pending on power-up, resume after 0 minute delay. SCT Status Version: 3 SCT Version (vendor specific): 256 (0x0100) Device State: Active (0) Current Temperature: 30 Celsius Power Cycle Min/Max Temperature: 27/41 Celsius Lifetime Min/Max Temperature: 19/48 Celsius Under/Over Temperature Limit Count: 0/0 SCT Temperature History Version: 2 Temperature Sampling Period: 1 minute Temperature Logging Interval: 10 minutes Min/Max recommended Temperature: 0/70 Celsius Min/Max Temperature Limit: 0/70 Celsius Temperature History Size (Index): 128 (106) Index Estimated Time Temperature Celsius 107 2022-04-13 14:20 31 ************ ... ..( 7 skipped). .. ************ 115 2022-04-13 15:40 31 ************ 116 2022-04-13 15:50 30 *********** ... ..( 8 skipped). .. *********** 125 2022-04-13 17:20 30 *********** 126 2022-04-13 17:30 29 ********** 127 2022-04-13 17:40 30 *********** 0 2022-04-13 17:50 29 ********** ... ..( 20 skipped). .. ********** 21 2022-04-13 21:20 29 ********** 22 2022-04-13 21:30 28 ********* ... ..( 3 skipped). .. ********* 26 2022-04-13 22:10 28 ********* 27 2022-04-13 22:20 29 ********** 28 2022-04-13 22:30 29 ********** 29 2022-04-13 22:40 29 ********** 30 2022-04-13 22:50 30 *********** ... ..( 2 skipped). .. *********** 33 2022-04-13 23:20 30 *********** 34 2022-04-13 23:30 31 ************ ... ..( 65 skipped). .. ************ 100 2022-04-14 10:30 31 ************ 101 2022-04-14 10:40 30 *********** 102 2022-04-14 10:50 29 ********** 103 2022-04-14 11:00 29 ********** 104 2022-04-14 11:10 34 *************** 105 2022-04-14 11:20 30 *********** 106 2022-04-14 11:30 30 *********** SCT Error Recovery Control: Read: Disabled Write: Disabled Device Statistics (GP/SMART Log 0x04) not supported Pending Defects log (GP Log 0x0c) not supported SATA Phy Event Counters (GP Log 0x11) ID Size Value Description 0x0001 2 0 Command failed due to ICRC error 0x0002 2 0 R_ERR response for data FIS 0x0003 2 0 R_ERR response for device-to-host data FIS 0x0004 2 0 R_ERR response for host-to-device data FIS 0x0005 2 0 R_ERR response for non-data FIS 0x0006 2 0 R_ERR response for device-to-host non-data FIS 0x0007 2 0 R_ERR response for host-to-device non-data FIS 0x0008 2 0 Device-to-host non-data FIS retries 0x0009 2 20 Transition from drive PhyRdy to drive PhyNRdy 0x000a 2 20 Device-to-host register FISes sent due to a COMRESET 0x000b 2 0 CRC errors within host-to-device FIS 0x000d 2 0 Non-CRC errors within host-to-device FIS 0x000f 2 0 R_ERR response for host-to-device data FIS, CRC 0x0010 2 0 R_ERR response for host-to-device data FIS, non-CRC 0x0012 2 0 R_ERR response for host-to-device non-data FIS, CRC 0x0013 2 0 R_ERR response for host-to-device non-data FIS, non-CRC