Abe677

Solved (for now). JorgeB - thank you very much for your help. I moved the drive to another SATA power connection, cleared the new drive again, the rebuilt the array (in maintenance mode). Array rebuilt without issue and the server is running. The plan forward. Because I had "shucked" a number of drives in this system, I used molex-to-SATA power splitters for those drives. I wanted to avoid taping pins. Seems like one of those splitters may have a problem. If I had a time machine I might go back and avoid shucked drives in this specific build. There are other configurations, like my Jonsbo N2, where shucked drives are fine and no splitters required. Dell T30 server, so non-standard power inside. I have a SFF 750 watt PSU to replace the stock 290 watt unit. Waiting on a special 24-to-8 pin adapter for motherboard power (from the new PSU). When I next open the case I'll see how many potentional schucked drives I might have and make plans to replace them over time. The goal would be to get rid of the power splitters.

Well, the extended SMART test is still sitting at 10%. Since this is a Dell T30 I have to wrestle with the non-standard power situation. I've ordered a SFF PSU with ATX adapter plate hoping it will mount. Also ordered a 24-to-8 pin PSU adapter for motherboard power. The T30 was designed with space for 4 drives in it. I added a cage and 2 more drives. Maybe the PSU has gotten tired. Seems like a tired PSU would show other symptoms though. Update: Extended SMART test didn't produce any errors. Clearning the drive again, then will try adding it again. New PSU ordered. That will leave the motherboard and HBA as possible problems.

Thanks for the advice so far. I had moved the drive to another port on the HBA, then started a "erase and clear". I had originally set this for 2 passes, but stopped during the post-read on pass 1. No problems during the 45+ hours of pass 1. Last evening I brought the array up in maintenance mode and started the array sync. About 2 hours in the drive logged more read errors and the sync stopped. I stopped the array. I'm attaching another diagnostic file. Next I'm going to shut the server down , open it up again, and check cabling. I may move the drive power to another source, then try again. hulk-diagnostics-20250813-0747.zip

Sorry. Just added the file to my original post. I don't spend much time in this forum. Unraid has been trouble free for about 5 years for me.

Unraid 7.1.4. I do monthly scheduled parity checks. Check on 8/1 ran without error. A few days later I ran a user script to clean up but docker image file, which also ran without error. I decided to run the parity check again because I've been wondering if the docker cleanup script causes errors in the next scheduled parity check. (I don't run the script often enough to know. Just a theory I wanted to check.) During the follow-up manual parity check, one of the disks reports a number of read errors and it was removed from the array. Not the drive with the docker image file. I ordered a pair of new WD Red drives to match the size of my parity drive. Figured I might as well upsize the broken drive. I precleared one of the WD Red drives via an external USB cradle. I did one preclear pass and had no problems. I replaced the failed drive with the new WD Red, and the rebuild started. About 30 minutes into the rebuild, the replacement drive reported errors and left the array. I decided to run another preclear pass on the replacement drive while it was inside the case and connected via SATA. That preclear completed without error. This morning I added the replacement drive back into the array and the rebuild started. Again there were errors about an hour after I started the rebuild. I opened the server up and checked cables. This drive is connected via a HBA I added. I made sure the cable to the HBA was well connected. I re-seated the card. I decided to move the replacement drive to another port on the same HBA. As I write this, I'm running a 2-pass "erase and clear" preclear. I'm puzzled as to why the preclears all seem to run without a problem. If someone has thoughts or other things to consider, I'm all ears. hulk-diagnostics-20250811-0547.zip

I don't post here often so I appologize if this is the wrong place. I'm running the PhotoPrism docker. I admit I haven't done much with it lately. I was trying to figure out why my Unraid server logs a lot of these messages, and narrowed it down to starting the PhotoPrism docker. I'm not sure what this means. I've xfs_repaired every drive and they seem clean, but this is still appearing every time I start PhotoPrism. Any thoughts or ideas welcome. Dec 30 07:01:50 HULK kernel: XFS (md1p1): Metadata corruption detected at xfs_attr_shortform_verify+0x8d/0xcd [xfs], inode 0x2807db3 attr fork Dec 30 07:01:50 HULK kernel: XFS (md1p1): Unmount and run xfs_repair Dec 30 07:01:50 HULK kernel: XFS (md1p1): First 119 bytes of corrupted metadata buffer: Dec 30 07:01:50 HULK kernel: 00000000: 00 77 02 00 06 40 00 73 68 61 32 35 36 61 35 34 [email protected] Dec 30 07:01:50 HULK kernel: 00000010: 34 63 33 31 62 32 32 34 30 33 35 61 63 62 62 62 4c31b224035acbbb Dec 30 07:01:50 HULK kernel: 00000020: 61 36 37 32 31 34 35 65 36 32 66 63 62 34 34 63 a672145e62fcb44c Dec 30 07:01:50 HULK kernel: 00000030: 64 39 30 30 32 39 33 38 32 33 30 31 34 34 39 64 d90029382301449d Dec 30 07:01:50 HULK kernel: 00000040: 30 66 37 38 39 34 39 63 61 64 63 66 62 08 1f 0a 0f78949cadcfb... Dec 30 07:01:50 HULK kernel: 00000050: 7e 68 61 6e 64 61 74 64 35 35 3f 32 31 35 33 33 ~handatd55?21533 Dec 30 07:01:50 HULK kernel: 00000060: 34 3b 08 0a 00 66 69 7b 6d 6a 61 72 67 31 3c 3a 4;...fi{mjarg1<: Dec 30 07:01:50 HULK kernel: 00000070: 30 02 0e 04 75 5d 50 0...u]P

I feel like an idiot but some confusion on my part lingers. Just did a vanilla install of the InfluxDB docker on my up-to-date Unraid server. I didn't change anything since the default ports 8083 and 8086 were unused. When I attempt to connect via the "WebUI" context menu I get a "ERR_CONNECTION_REFUSED" error. So I google a bit and read some posts that the web UI has been depreciated and I should use console commands, but that goes nowhere. I see that the WebUI context menu is using port 8083. For the heck of it I change it to port 8086 and voila - a web UI that lets me set up InfluxDB. So is the Web UI depreciated? Is there was port swap in the docker template?

Guessing here. The document date is being picked up via something it thinks is a document date after OCRing it. I suspect if you look at the document properties in p-ngx you might see the connection. I have my new documents tagged with "inbox" automatically so I can easily find them when I use the web app. Then I can update the metadata and remove the inbox tag.

Unraid 6.11.5, Docker version status for paperless-ngx has been "not available" for around a day. I update these things routinely so it's odd. db-backup docker also in this state but only those 2 (of 20). Repo says "ghcr.io/paperless-ngx/paperless-ngx". Best I can tell it's still there. UPDATE: Installed the CA Docker Patch plugin and all seems well again.

I see there at least a couple of posts about this, but no explanation. I just upgraded from 6.9.2 to 6.11.5 and also see the stream counts are always zero. In 6.9.2 the stream count was somewhat useful for determining what shares were in use. Also a good post-reboot sign that things were working. Now that the stream count is always zero, I'm not sure what to make of it? Bug? Feature? Things seem to be working on my server so I can't say anything is broken. (Upgrade was easy by the way - thank you!)

I updated from ng to ngx some time ago. I'm using dyndns and have things set so I can go to: site.my_domain.dyndns.org I have NGINX running and have paperless.my_domain.dyndns.org pointing to my unraid server IP address port 8001. While on my LAN, https://<unraid_server_ip_address>:8001 works as you'd expect. Works great. When outside my LAN, paperless.my_domain.dyndns.org -> NGINX gets me to the paperless credentials login page, but after I enter my usual username and password I get a long pause followed by "504 Gateway Time-out" and "openresty" underneath that message. I have the paperless app on my android phone. It's been "logged in" forever and seems to work. Turned off the wi-fi. Still works. I logged out of the paperless app, then back in. Used https://paperless.my_domain.dyndns.org. Entered my credentials. Get an error 504 after a long time. Kill the android process. Start the paperless app again and I can see my documents. I've checked the NGINX and paperless-ngx docker logs and don't see an error message. Browser access from outside my house would be useful. The phone app behavior seems odd. (I don't expect phone app help or support here, just providing information.) Wondering if there's a guide or post on how to do this "right" because I'm obviously missing something.

My Docker default is set to "/mnt/user/docker/appdata/". The following containers are using this path: mariadb (/mnt/user/docker/appdata/) PlexMediaServer (/mnt/user/docker/appdata/) QDirStat (/mnt/user/docker/appdata/) nextcloud (/mnt/user/docker/appdata/) binhex-krusader (/mnt/user/docker/appdata/) Handbrake (/mnt/user/docker/appdata/) The following have no appdata that I can tell: Redis (none) OpenSpeedTest (none) db-backup (none) The following have a appdata path different than the default: bookstack (/mnt/user/bookstack/) paperless-ng (/mnt/user/appdata/paperless-ng/data) Nginx (/mnt/user/NGINX/) Influxdb (/mnt/user/appdata/influxdb) I suspect I was following various tutorials to set these up and wasn't aware all the container "appdata" data needed to be in one place. The good news is that the 4 containers that are not set up correctly could be nuked and set up properly. I suppose if I was clever I could shut those containers down, move that data to the proper location, change the container setting, and they should start. I'll have to think about this.

I've been trying to search this topic without much luck. I'd like to run this plug-in. I'd sort of a Unraid rookie. I have an appdata share and when I look at its contents I don't see folders for every docker I'm running. When I edit each docker and look around, I see I have appdata folders "spread around." So a few questions come up. If I do nothing, with this plug-in find the appdata folders for each docker and back them up regardless of their location? Do I need to fix this appdata location problem? If so, is the only solution re-installing each docker while paying more attention to where the appdata folder end up?

I can't answer your specific question about inotify on Unraid. I'm playing with Paperless-ng on my Unraid server and it seems to see and process files in the consume folder with no problem. I would describe my experience this way - Paperless-ng works great on an Unraid server, and you will spend more time thinking about things like tags and workflow than actually getting it to work.

Yes you are completely correct. I hadn't thought to look at the original project. Thanks!