writablevulture

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