writablevulture

These disclosures are appreciated, thanks. For a machine on v6.12.14, does the Patch Plugin mitigate only vulnerability 1 as suggested in the blog post or all four vulnerabilities?

Thank you, that wasn't the IP address I was expecting. It looks like my router simply lost the DHCP reservation for my server. I have no idea why; the reservation for my KVM over IP was fine but the actual Unraid IP reservation just got lost. I suppose that is what I get for using my ISP's supplied router. It's so frustrating - in the end my server was fine, I was just hitting the wrong IP address and I just hadn't spotted it.

Thank you, it took me a while to manage to get a network path mounted to get the diagnostics off, but I have now attached them. I don't see anything in them that is so catastrophic that I can't get to the Web GUI or log in via SSH. If anyone can help me understand what is going on here I'd be grateful. Thanks! tower-diagnostics-20240614-2102.zip

Unraid v6.12.10 I am currently unable to navigate to the Unraid GUI or via SSH (the connections time out). Initially, that was all that was wrong; all my Docker containers continued running. So, I rebooted my server and still have the same problem but now most of my Docker containers seem not to be running. Sometimes, after rebooting Uptime Kuma is running and sending notifications about my other containers not accepting connections. I do not understand why this has suddenly happened - I did perform a "diagnostics" on the command line (via KVM over IP) which I have looked at and I can't see anything obvious in there but I am sure I have missed something. I would like to share my diagnostics here but I want to check: if I create the diagnostics via the CLI, are they anonymised? Is there a particular argument I need to supply to anonymise them? Thanks!

I also have this issue. I have "Notification Settings" set to "Errors Only" but I am getting a daily e-mail about successes. If this new final message could honour the "Notification Settings" I think it would be a great improvement, thank you!

I'd like to replace a disk in my pool but keep the existing one and use for something less critical as it starting to show signs of failure. The Unraid documentation states: Why do I need to do step (2)? Can I not just leave it attached and then repurpose it for something else? I don't really want to open my machine up at all because both the disks in question are already in there and it is not easily accessible. Thanks!

Trying run xfs_reapir without the -n flag gives the same message that it did with the -n flag: Sorry, could not find valid secondary superblock Exiting now. ...and it is still listed as unmountable. Is that the end of the road for this?

Thanks. Can I repair the new disk that I rebuilt from parity? Or should I reintroduce the original disk that first reported problems?

Recently I have been getting notifications that the "Reported uncorrect" SMART attribute was increasing for one of my drives. It is a small (500GB) drive so I thought the best action is to free up some space on my array then use unBALANCE to move all the files off that disk to the rest of the array before removing it. However, whilst running unBALANCE, the unBALANCE UI froze up and then when I looked at the drive in the Unraid UI, I was told that the drive was "Unmountable: Wrong or no file system". Looking in the syslog I was led to try an xfs_repair but that was unable to repair the drive. My next step was to simply replace the drive and rebuild from parity which took around 3 hours. It completed without any obvious errors but to my surprise the new drive was also listed as "Unmountable: Wrong or no file system". So, if parity can't help me do I just have to take the loss of the drive and its data? I have backups of anything important and the rest is just media that can be found again. I have attached diagnostics in case there is something else I could try - thanks for any advice. tower-diagnostics-20230510-0831.zip

Ah, that means I don't really need to move this disk to a pool at the moment - that's great. Thanks.

When you say "manage", can Unraid spin an UD drive down after a certain period of inactivity? I don't seem to be able to find that setting anywhere whereas I can see it for non-UD driives.

I have an exFAT unassigned device which I'd like to make a single BTRFS drive pool so that it's spin-up/down can be controlled by Unraid. Is there a way of doing this that doesn't require me to copy all of the existing data off and then back on again? Thanks!

I have recently got the following error in Fix Common Problems: I have attached my logs. There seem to be a lot of errors starting from May 2 20:38:55 in my syslog. I have attached my diagnostics, could anyone help work out what has gone wrong please? I have noticed any negative effects from this event yet. tower-diagnostics-20230503-0928.zip

If I exclude a container's appdata directory from being backed up, will that container still be stopped and restarted even though it isn't being backed up. I can't quite tell from the UI. Thanks!

A solution from a few posts back:

I tried unseating/reseating the cable, changing the cable and using an alternative SATA port without success - so I guess the drive is genuinely dead. I have removed it from the pool and ordered a replacement. Thanks!

After the entries in my syslog.1 file on the 23rd of October, my syslog file is totally empty. So, no log entries for 48 hours. That just seems odd to me, I was wondering if you (or anyone else) think that's unusual.

Thanks, I will as soon as I get access to my server. The drive does appear to be back online as I can see reads & writes to & from it. Do you think it is unlikely that after that there has been nothing at all in my syslog since, for two days now?

I got a warning telling me that: **/var/log is getting full (currently 100 % used)** Looking at my syslog I have many entries telling me that: Tower kernel: sd 7:0:0:0: [sdg] tag#1 access beyond end of device Although there are many of these entries on the 23rd of October along with lots of other BTRFS errors such as: Tower kernel: BTRFS warning (device sdg1): lost page write due to IO error on /dev/sdg1 (-5) Tower kernel: BTRFS error (device sdg1): error writing primary super block to device 2 ...I suddenly get no entries in my syslog at all after the 23rd which seems odd. "sdg" is one of my two cache drives and looking at my cache it is only about 50% full. I can't really tell if: Perhaps my cache just got full on the 23rd leading to these errors and then whatever filled it up was deleted, so the errors stopped. But I find it odd that I no longer have any syslog entries after the 23rd. Or my sdg drive is somehow defective and I should replace it. I'd appreciate any insight anyone can give on this (diagnostics attached), thanks! tower-diagnostics-20221025-0943.zip

I am using the Fix Common Problem plugin to e-mail me nightly when there is an update to my docker images. For the stack that I created using the Dokcer Compose Manager plugin, I get an e-mail every night irregardless of an actual update being available or not. Is this the same issue reported above? Is it just somehting that I have to accept using Dokcer Compose Manager?

I have now discovered that you can pass in the location of the atomicparsley binary when executing get_iplayer: --atomicparsley /usr/sbin/atomicparsley You will then find that tagging works as expected.

I can confirm the issue is no longer present in latest. Thanks!

I am about to upgrade to Unraid 6.10.3 and have just run the Update Assistant which gives me this issue: I am aware of the issue in other 6.10.x releases for certain machines including my HP Gen 8 Microserver, but I understand that the primary purpose of the 6.10.3 release was to fix that issue as described here in the official release post. I am confused as to what to do here. The official release notes indicate that everything should be alright now because the Linux kernel default IOMMU operation mode has been changed from "DMA Translation" to "Pass-through" but the Update Assistant says I need to disable IOMMU in the bios. Do I need to disable IOMMU or is the Update Assistant's advice out of date? Thanks!

I ran the container for a few days without specific servers and then queried InfluxDb to get a list of servers that are typically used from my location. I removed any that didn't consistently max out my connection and then used that list for the "SERVERS" environment variable. There is also this list but I don't know how up to date it is.

You can choose specific servers by providing a comma-separated list of server IDs as an environment variable called "SERVERS" - I do this myself. Is that what you mean by locations? The documentation suggests you need to surround the list in parentheses but I find that this causes the container to fail.