socono

I recently noticed the same panic errors in my log with photosync kicking out an error at the same time while trying to transfer. I disabled the 'Transfer to Temporary file' option about 3/4 of the way through the multi retry attempts and it finished without panics.. Nothing conclusive. Will test more over the next few days

I became too impatient and went ahead with the xfs_repair and it seems to have resolved the issue.

High level overview of recent events on my Server: 1. Parity Disked swapped out for larger size. Completed successfully no errors in logs. 2. Data disk (md2) swapped out for larger disk. During the rebuild, syslog noted some failed command: READ FPDMA QUEUED errors on two other data drives. Rebuild paused and server powered off to reset cables. 3. Server powered on and md1 and md6 both would not mount. However, the array autostarted and rebuild said it continued on md2. 4. Powered off server , sata cables replaced for md1 and md6 and powered on. ATA errors no longer seen in log for md1 and md6 but both will not mount. Log indicated corruptions. 5. Array put into maint. mode and xfs_repair run on both md1 and md6 successfully. 6. Array started and data rebuild for md2 continued. During this time the log begins to report XFS (md2): Corruption detected. Unmount and run xfs_repair. I let the rebuild complete. 7. After rebuild complete, ran xfs_repair -n on md2 and see the message Inode allocation btrees are too corrupted, skipping phases 6 and 7 which I have never seen before. Can I safely run xfs_repair on md2? Thanks for your time. tower-diagnostics-20220417-2145.zip

I had the same errors and found the comment in the below link about adding " --user telegraf:$(stat -c '%g' /var/run/docker.sock) " to the container parameters worked for me. https://github.com/influxdata/telegraf/issues/10050

I'm working through the same problem. This started after the upgrade to 6.7.0 for me. I have 35 Docker containers on my list and about 5 of them no longer show the WebUI link in the drop down where they did before. Their Webui field in advance settings is defined and I've tried setting it to the actual link as well as using the http://[IP]:[PORT:8083]/ to no avail. Can't see anything in syslog or the Docker log that is complaining.

I had the problem as a few who have posted where right after install the UI is not available. Note the docker installer defaults to 'eth0' for the 'Interface' value. My interface on my Unraid local network is not eth0. Changed this value to br0 in my case and I can access the UI right after install now. So log into your Unraid console and do an ifconfig. find the interface with your IP on your local network and put that in the key for 'Container Variable: INTERFACE'