JPilla415

Yea, I think that the docker was created using AI tooling, and the developer seems to have moved on to other projects. I worry that it will be abandoned, which is why I am looking into other solutions. I will look into producing a script. Thanks.

Thanks, this Docker container has no appdata files to edit. My last post may not have been clear, but the process you outlined is the first step that I tried. I also tried the extra parameters route. Thanks very much for the suggestion though.

Thanks so much for the assistance and apologies for the lack of clarity in my original post. The method you outlined in your linked post was how I attempted to set the PUID, PGID and UMASK variables. I also tried to add: "--user 99:100 --env UMASK=000" as extra parameters, shown below:

Hello, I am working with a docker container, which does not support PUID, PGID, or UMASK environment variables. The container is available here: https://github.com/juaniwck/mister-retroarch-save-sync I am currently having an issue where the container is creating new files with the following permissions: -rw-r--r-- I have attempted to add the necessary environment variables via the Docker configuration UI, as well as adding "--user 99:100 --env UMASK=000" as additional parameters. In both cases, new files continue to be written with the following permissions: -rw-r--r-- Ultimately, I want the docker to write directories with the following permission: drwxrwxrwx and for files: -rw-rw-rw-. Are there any suggestions for how I might force the correct permissions to be applied?

Thank you both. I will mark this as resolved then.

Since writing my original post, reads have gone up to 58,703 and writes to 567. Again, just not sure what is considered normal. Appreciate any insights.

My server, running 7.0.1 has been up for 4.5 days and I am currently seeing 57,962 reads from the flash drive, and 548 writes. I see that there is a known issue with Unraid 7.0 around excessive USB usage. I am just not clear on whether or not this is considered excessive? Is there a known good baseline? Diagnostics attached, if they are needed. tower-diagnostics-20250702-0919.zip

This may be the wrong place to ask, but will we see an update to "Update Assistant" to check against 7.1 soon? It seems to still be checking against 7.0.1.

Thanks very much

Hello all - Thank you in advance for any recommendations on the best course of action. My goal is not speed, but safety of data. Current Server/Scenario: Running Unraid 6.12.14 1x 20TB Parity Drive 13x Data drives of varying sizes I have maxed out my available drive slots in my case. All drives are healthy Goals: Shrink array by 1x data drives Install new, larger parity drive Historically, I have used the "Unbalanced" plug-in to move all data off of a drive and then run the "clear an array drive" script to remove a drive from the array while maintaining parity. From what I understand, this is no longer a recommended approach. Is there another method that can be used that will maintain parity? Or is the recommended approach to: Move all data off data drive, which is going to be removed Stop the array Unassign the data drive and current parity drive assignments Start the array Stop the array Physically remove the data drive Physically remove parity drive Install the new larger parity drive Start the server in maintenance mode Rebuild parity Appreciate the guidance and thoughts.

Thanks so much for taking a look. I appreciate it.

I recently pre-cleared a new disk, using a USB external enclosure. The pre-clear process went fine, no errors detected. Log attached. However, in my system logs, there were several I/O errors, like so: May 25 14:07:25 Tower kernel: I/O error, dev sdq, sector 216176640 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 25 17:46:47 Tower kernel: I/O error, dev sdq, sector 7100000256 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 25 19:29:54 Tower kernel: I/O error, dev sdq, sector 10371895296 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 25 21:46:52 Tower kernel: I/O error, dev sdq, sector 14667474944 op 0x0:(READ) flags 0x80700 phys_seg 235 prio class 3 May 25 23:15:57 Tower kernel: I/O error, dev sdq, sector 17367803904 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 25 23:25:31 Tower kernel: I/O error, dev sdq, sector 17650579456 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 25 23:28:55 Tower kernel: I/O error, dev sdq, sector 17751074816 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 26 02:26:36 Tower kernel: I/O error, dev sdq, sector 22836414464 op 0x0:(READ) flags 0x80700 phys_seg 143 prio class 3 May 26 04:42:18 Tower kernel: I/O error, dev sdq, sector 26456676352 op 0x0:(READ) flags 0x80700 phys_seg 250 prio class 3 May 26 05:30:42 Tower kernel: I/O error, dev sdq, sector 27685124096 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 26 05:47:47 Tower kernel: I/O error, dev sdq, sector 28108584960 op 0x0:(READ) flags 0x80700 phys_seg 255 prio class 3 May 26 06:38:47 Tower kernel: I/O error, dev sdq, sector 29346476032 op 0x0:(READ) flags 0x80700 phys_seg 255 prio class 3 May 26 06:55:44 Tower kernel: I/O error, dev sdq, sector 29748836352 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 26 09:56:49 Tower kernel: I/O error, dev sdq, sector 33768067072 op 0x0:(READ) flags 0x80700 phys_seg 177 prio class 3 May 26 12:35:24 Tower kernel: I/O error, dev sdq, sector 36843491328 op 0x0:(READ) flags 0x80700 phys_seg 248 prio class 3 May 27 16:50:40 Tower kernel: I/O error, dev sdq, sector 829847552 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 27 17:23:38 Tower kernel: I/O error, dev sdq, sector 1869090816 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 27 18:14:28 Tower kernel: I/O error, dev sdq, sector 3488593920 op 0x0:(READ) flags 0x80700 phys_seg 255 prio class 3 May 27 18:17:12 Tower kernel: I/O error, dev sdq, sector 3575107584 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 27 18:30:54 Tower kernel: I/O error, dev sdq, sector 4006899712 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 27 22:18:08 Tower kernel: I/O error, dev sdq, sector 11223660544 op 0x0:(READ) flags 0x80700 phys_seg 254 prio class 3 May 27 22:38:32 Tower kernel: I/O error, dev sdq, sector 11866187776 op 0x0:(READ) flags 0x80700 phys_seg 218 prio class 3 May 27 22:47:46 Tower kernel: I/O error, dev sdq, sector 12155328512 op 0x0:(READ) flags 0x80700 phys_seg 255 prio class 3 May 28 02:27:18 Tower kernel: I/O error, dev sdq, sector 18810028032 op 0x0:(READ) flags 0x80700 phys_seg 99 prio class 3 May 28 02:53:56 Tower kernel: I/O error, dev sdq, sector 19580878848 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 28 03:22:13 Tower kernel: I/O error, dev sdq, sector 20390768640 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 28 04:57:37 Tower kernel: I/O error, dev sdq, sector 23055421440 op 0x0:(READ) flags 0x80700 phys_seg 36 prio class 3 May 28 06:07:08 Tower kernel: I/O error, dev sdq, sector 24922828800 op 0x0:(READ) flags 0x80700 phys_seg 211 prio class 3 May 28 07:18:30 Tower kernel: I/O error, dev sdq, sector 26779922432 op 0x0:(READ) flags 0x80700 phys_seg 167 prio class 3 May 28 09:10:28 Tower kernel: I/O error, dev sdq, sector 29533231104 op 0x0:(READ) flags 0x80700 phys_seg 248 prio class 3 May 28 10:02:02 Tower kernel: I/O error, dev sdq, sector 30733670400 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 May 28 13:04:12 Tower kernel: I/O error, dev sdq, sector 34633654272 op 0x0:(READ) flags 0x80700 phys_seg 256 prio class 3 I'm under the assumption is this due to a flaky USB enclosure disconnecting and reconnecting, but I wanted to ask the experts to be sure. Diagnostics attached. Appreciate any thoughts and feedback! preclear_disk_8LJBK2XN_8429.txt tower-diagnostics-20240529-0718-ANON.zip

Shoot! Didn't think about that. Thanks very much!

Forgive me if I am missing something painfully obvious, but the new Unbalanced UI is indicating the following: However, when looking through /var/log via Krusader, I am not seeing any log file. The last modified date for /var/log is back in 2023 for me. Appreciate the help!

28 hour MemTest with clean results! Booting back up the server again after several days of downtime. Fingers crossed! Thanks again for all the help.

Thanks so much!

Thanks very much for the time and help on this! I'll go ahead and mark the MemTest post from you as the solution. If other issues crop back up, I'll come back to the thread and add more details. Fingers crossed this is the end of it. Is there a current recommendation for my RealTek Adapter, it's unclear to me if I should be using the RealTek plug-in or not:

I had similar BTRFS errors in my logs last week, and the first step recommended to me from the team here was to run a MemTest.

12 hours and error free with the new ram. I'm going to let this run the rest of the day to play it safe. Assuming I encounter no errors in the next 12-24 hours, what is the recommended next step to troubleshoot my slow cache write performance outlined earlier in the thread? Just go back to normal day-to-day use of the server and see if the issue pops up again? Thank you again for all of the help!

Understood, will do thanks again!

Much appreciated. I will start to track down some new ram and report back. Sorry to repeat this: but would failing memory explain the drop in cache write speeds I have been observing? Or is that likely another scenario which I will need to troubleshoot after getting new ram. Thanks again.

I believe the recommendation is to run Memtest for a full 24 hours, but given that I am 12 hours in and have already logged 462 errors, I'm suspecting this is enough data to call my dimms bad? Is that that the general consensus? I assume even one error is above a comfortable threshold. If so, I need to work on tracking down some ram compatible with my motherboard and CPU. I am using older hardware and I am not clear on whether or not ram is still manufactured or available. Are there current recommendations around ram? Is it better/worse to utilize all four slots on the motherboard? If I have been comfortably running 16GB for years, is there any reason to bump to 32GB? If I move from 4 dimms to 2 dimms, is that going to present any sort of issue? I assume the answer to all of these is no, but better to check than be surprised. Last question, would failing memory explain the drop in cache write speeds I have been observing? Appreciate everyone's time and thoughts.

Understood, thank you very much for the suggestion. Running a memtest now. I will report back tomorrow.

I've made no changes to my network, Unraid or PC. Tried another copy to the Unraid cache and this is what I am seeing now. These are the speeds I am used to seeing.

Hello, sincere appreciation in advance for any guidance and thoughts from the community on this topic. Over the last several weeks, I have noticed in some instances the speeds with which I can write TO my cache drive will drop significantly. I use Teracopy to write files to my server, and in these instances of poor cache write performance, I will frequently get an error that the hashes don't match for the files written to the server. In each case, when troubleshooting the issue I have rebooted my server, and it has resolved the issue for some amount of time. An example of the change in write speed is as follows: Average normal write speed: 85-90 MB/s Average degraded write speed: 25-40MB/s Here is the current write speeds to my Unraid Server, writing to SSD Cache drive: As a point of comparison, here are the write speeds to my Synology server, no cache SSD. The same source computer, same network, same router, same switch, same file are being used for both servers: It is worth noting that in this window, I updated to Unraid 6.12.6 and I understand that there are potential networking issues with RealTek adapters. Last week I downloaded the suggested RealTek driver from the Fix Common Problems Plug-in but the same issue popped up. I removed the plug-in yesterday. Here is the information being shown in my system devices for the network adapter: I have also noticed the following errors in my system log from this morning: I also had BTRFS errors in my logs over the past several days. I suspect these are related, but I can't be certain. Apologies if I am conflating two separate issues, but I wanted to share as much as possible. I have attached Diagnostics, as well as my system logs from these periods. My apologies for the noise in the logs, when rebooting my server, a new IP address was assigned and the server lost access to the UPS. I didn't notice the noise in the logs from this until today. I copied and pasted errors above. Please let me know if I can provide any other useful information. Thanks so much! tower-syslog-20240120-1710.zip tower-diagnostics-20240120-0909.zip tower-syslog-192.168.1.2-20240120-1711.zip