ericswpark

I also had to change configurations of some Docker apps, because the underlying Docker network changed from 172.18.0.x to 172.17.0.x. Something to keep in mind if some services are not resolving after the rebuild.

So the parity check completed without errors, so I stopped the array to begin maintenance. Wiping the cache pool was relatively simple (I was definitely overthinking things – for future reference, unassign the SSD from the pool, run `blkdiscard -f /dev/nvmeXnX` with your drive number, then reassign to pool, and erase). Once I verified that the long SMART passed for dev1 I re-assigned the drive back to Disk 1 and started the array. Then I rebuilt the Docker images and started restoring the appdata. Hopefully this helps someone else who has the same issue!

Can the spin-up/down indicator of the unassigned disks be disabled when a SMART test is running? Accidentally clicked on them because I was managing on my tiny phone screen and thought I'd have to restart the 14+ hour long SMART test. Thankfully the drive didn't abort the test but I'd like to prevent something like this happening in the future.

Hi all. Just suffered a power outage at my house, no UPS. (Learning the hard way... one has since been ordered) When the server came back up I found the following: 1. Disk 1 was missing (wouldn't even show up under unassigned devices) 2. Cache pool showed uncorrectable errors during a scrub Strangely, even though the server had uncleanly shut down, there was no parity check. Maybe because Disk 1 was missing? Anyway, I ran the parity check, and after 20 minutes checked back in to see Disk 1 sitting in the UD section. I guess it needed time to wake back up after getting the power cut. All the SMART attributes looked fine but I wanted to make sure that it won't die on me again or something, so I ran a short SMART (passed) and a long SMART (still running, 20% left at this point) to make sure it won't die again during the rebuild. Now since the server is configured in dual parity I'm not worried about data loss. What I am worried about is the cache pool since that holds the appdata. I do keep daily backups with the backup plugin, so worst case scenario is I lose about less than a day's worth of changes. But I wanted to see if I can just use the current data. However, the scrub command won't tell me exactly which files are affected. In the logs I see the following: [42493.446568] BTRFS error (device dm-3): bdev /dev/mapper/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 32, gen 0 [42493.446579] BTRFS error (device dm-3): unable to fixup (regular) error at logical 82579787776 on dev /dev/mapper/nvme0n1p1 [42493.929861] BTRFS error (device dm-3): bdev /dev/mapper/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 33, gen 0 [42493.929871] BTRFS error (device dm-3): unable to fixup (regular) error at logical 85866598400 on dev /dev/mapper/nvme0n1p1 [42496.080932] BTRFS error (device dm-3): bdev /dev/mapper/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 34, gen 0 [42496.080942] BTRFS error (device dm-3): unable to fixup (regular) error at logical 100984004608 on dev /dev/mapper/nvme0n1p1 [42501.552701] BTRFS error (device dm-3): bdev /dev/mapper/nvme0n1p1 errs: wr 0, rd 0, flush 0, corrupt 35, gen 0 [42501.552709] BTRFS error (device dm-3): unable to fixup (regular) error at logical 136209657856 on dev /dev/mapper/nvme0n1p1 But when I run `btrfs inspect-internal logical-resolve <logical_address> /mnt/cache` it returns nothing for all four affected addresses. BTRFS check (read-only) reports that there are no errors. I've stopped the Docker service to prevent further damage (stopped before all the checking and triage – so about 15-20 minutes after the server came up) and had a backup taken (again, with the uncorrectable errors – so I'm guessing some files in there are corrupt?) At this point this is my plan for the day: 1. Wait for parity check to complete (hopefully without any errors; if there are then it's another 14 hours worth of parity checks with the write corrections turned on. Is there a way to just fix the errors without rerunning the entire thing?) 2. Stop the array 3. Wipe cache pool (how? Can't find the format button... does it show up when the array is stopped?) 4. Make sure long SMART for dev1 passes 5. Reassign dev1 to Disk 1 6. Start array 7. While rebuilding, restore appdata backup Is the plan okay or should I do something else? Anything I've missed? Feedback would be appreciated! Attached diagnostics. dipper-diagnostics-20230326-1022.zip

Thanks @JorgeB. I've just added the swapfile plugin to the server. I'll post here if OOM happens again.

Hi, recently I've been getting OOM errors on my server from the Fix Common Problems plugin. I've noticed (but am not 100% sure) that it usually happens when we're streaming something from Plex. Plex has been set up to use the ramdisk (`/dev/shm` to `/transcode`) as a temporarily transcode dumping ground. But my understanding is that this ramdisk will never cause OOM and cause the kernel to randomly kill off processes with the oom-killer. Attached diagnostics. Any suggestions would be appreciated! dipper-diagnostics-20230320-2355 2.zip

After further testing, here's the config that worked for me: server min protocol = SMB3_02 client ipc min protocol = SMB3_11 So iOS/iPadOS devices running 16.3.1 seem to only support SMB as it was developed/implemented in Windows 8.1 days. (For reference: `SMB3_02` is Windows 8.1 implementation, while `SMB3_11` is Windows 10 (not 11).) The `client ipc min protocol` does not matter, so you can leave it on `SMB3_11` and it will not make a difference. This config works for both the built-in SMB provider in the Files app, and for the FE File Explorer Pro app. I can confirm even the latest stable release of iOS VLC works too on this config, which suggests to me that either the app was finally fixed or that iOS devices just don't support `SMB3_11` as a whole for the server minimum protocol.

The following two lines cause SMB to stop working on iOS devices: #server min protocol = SMB3_11 #client ipc min protocol = SMB3_11 I haven't experimented with exactly which line is causing the problem, but I guess iOS devices don't support SMBv3 yet. Tested on the latest iOS/iPadOS 16 release. All the other configuration options don't cause a problem so feel free to keep them enabled. On Files app, you get an Operation Not Supported error, and the FE File Explorer app shows a "Permission denied" error and asks to sign in again.

Figured out the problem: the "Enhanced macOS Interoperability" setting was causing the issue. Turning it off fixed it. What Samba configurations does this option add?

All the shares I tested with were set to Private access, but I just tried with a dummy share set to Public and it still didn't work.

Hi everyone, for the last couple of weeks (months?) I've been trying to solve this weird problem I'm having with one of my iOS apps I'm using, Cryptomator, to access encrypted vaults on the server. All details are in this GitHub issue: https://github.com/cryptomator/ios/issues/265 But the TL;DR is the app cannot identify a vault on unRAID's SMB implementation only. (Or it's a configuration issue with one of the SMB config options in unRAID, but I can't figure out what.) Basically, the bug occurs when adding an existing vault – the Cryptomator app requests the directory listing from the iOS File Provider, which returns a list of files within the directory that the user chose, indicating that it is a vault. The problem is that when choosing a vault on unRAID, the file provider returns nothing, and the app bugs out because it wasn't returned anything. This is in spite of the fact that the user has access and the necessary permissions to read/write to the share, and also in spite of the fact that I can actually see the vault files listed inside the iOS Files app. To verify that this was a unRAID specific issue, I spun up a Debian VM and installed Samba on it and tried to reproduce the problem on that but it worked without a problem. So something on my unRAID server is causing the incompatibility with Cryptomator, but I can't figure out what. My SMB extras configuration is empty. This is what my SMB config page is set to: The only change I have regarding SMB is the recycle bin plugin. I've tried transplanting the configuration options from unRAID to the Debian server to try and break compatibility there, but have so far been unsuccessful. What is the difference between unRAID's Samba config and a vanilla Debian install's Samba config? Can anyone try out the Cryptomator app to see if they have a similar problem adding an existing share on an unRAID vault?

Unfortunately this plugin isn't working correctly for me. Today it gave me a notification saying that 82 files on my array were corrupt. When I checked the files deemed corrupt by the plugin the hashes matched up to the values in the extended file attributes, so I have no idea where the plugin got the idea that my files were corrupt. It honestly shows how unreliable the plugin is when these "corruption" notifications don't even faze me in the slightest.

Yeah, that's why I was a bit confused. It looks like the Dynamix temperature plugin's script may be broken, or it might be getting confused because `sensors-detect` claims that the driver for the ITE IT8655E chip does not exist yet (`to-be-written`), which might be tripping up the detection in the plugin? Just a guess. Manually loading the driver by editing the configuration file fixed it. Thanks!

Finally managed to get the temperature to show up in the plugin. Turns out the "detect" button is broken and does not scan available drivers properly. Following this comment: I had to create a `drivers.conf` file in `/boot/config/plugins/dynamix.system.temp` and add the following two lines: it87 k10temp Then once I went back to the temperature plugin settings I was able to select the CPU/MB temperature from the dropdown. One thing to note – already mentioned in the linked comment but just to make sure – don't click on "Detect" or else it will wipe out your changes and you'll have to start over. The commenter in the link had to do the `modprobe force_id` thing, but I didn't have to thanks to this plugin. You probably shouldn't need it if you have this it87 plugin installed.

@ich777 here's the output from `sensors-detect`: root@dipper:~# sensors-detect # sensors-detect version 3.6.0 # Board: ASUSTeK COMPUTER INC. PRIME A320I-K # Kernel: 5.15.46-Unraid x86_64 # Processor: AMD Ryzen 5 PRO 4650G with Radeon Graphics (23/96/1) This program will help you determine which kernel modules you need to load to use lm_sensors most effectively. It is generally safe and recommended to accept the default answers to all questions, unless you know what you're doing. Some south bridges, CPUs or memory controllers contain embedded sensors. Do you want to scan for them? This is totally safe. (YES/no): Silicon Integrated Systems SIS5595... No VIA VT82C686 Integrated Sensors... No VIA VT8231 Integrated Sensors... No AMD K8 thermal sensors... No AMD Family 10h thermal sensors... No AMD Family 11h thermal sensors... No AMD Family 12h and 14h thermal sensors... No AMD Family 15h thermal sensors... No AMD Family 16h thermal sensors... No AMD Family 17h thermal sensors... No AMD Family 15h power sensors... No AMD Family 16h power sensors... No Hygon Family 18h thermal sensors... No Intel digital thermal sensor... No Intel AMB FB-DIMM thermal sensor... No Intel 5500/5520/X58 thermal sensor... No VIA C7 thermal sensor... No VIA Nano thermal sensor... No Some Super I/O chips contain embedded sensors. We have to write to standard I/O ports to probe them. This is usually safe. Do you want to scan for Super I/O sensors? (YES/no): Probing for Super-I/O at 0x2e/0x2f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... Yes Found `ITE IT8655E Super IO Sensors' Success! (address 0x290, driver `to-be-written') Probing for Super-I/O at 0x4e/0x4f Trying family `National Semiconductor/ITE'... No Trying family `SMSC'... No Trying family `VIA/Winbond/Nuvoton/Fintek'... No Trying family `ITE'... No Some systems (mainly servers) implement IPMI, a set of common interfaces through which system health data may be retrieved, amongst other things. We first try to get the information from SMBIOS. If we don't find it there, we have to read from arbitrary I/O ports to probe for such interfaces. This is normally safe. Do you want to scan for IPMI interfaces? (YES/no): Probing for `IPMI BMC KCS' at 0xca0... No Probing for `IPMI BMC SMIC' at 0xca8... No Some hardware monitoring chips are accessible through the ISA I/O ports. We have to write to arbitrary I/O ports to probe them. This is usually safe though. Yes, you do have ISA I/O ports even if you do not have any ISA slots! Do you want to scan the ISA I/O ports? (yes/NO): Lastly, we can probe the I2C/SMBus adapters for connected hardware monitoring devices. This is the most risky part, and while it works reasonably well on most systems, it has been reported to cause trouble on some systems. Do you want to probe the I2C/SMBus adapters now? (YES/no): Using driver `i2c-piix4' for device 0000:00:14.0: AMD KERNCZ SMBus Module i2c-dev loaded successfully. Next adapter: SMBus PIIX4 adapter port 0 at 0b00 (i2c-0) Do you want to scan it? (YES/no/selectively): Client found at address 0x50 Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... Yes (confidence 8, not a hardware monitoring chip) Probing for `EDID EEPROM'... No Client found at address 0x51 Probing for `Analog Devices ADM1033'... No Probing for `Analog Devices ADM1034'... No Probing for `SPD EEPROM'... Yes (confidence 8, not a hardware monitoring chip) Next adapter: SMBus PIIX4 adapter port 2 at 0b00 (i2c-1) Do you want to scan it? (YES/no/selectively): Next adapter: SMBus PIIX4 adapter port 1 at 0b20 (i2c-2) Do you want to scan it? (YES/no/selectively): Next adapter: AMDGPU DM i2c hw bus 0 (i2c-3) Do you want to scan it? (yes/NO/selectively): Next adapter: AMDGPU DM i2c hw bus 1 (i2c-4) Do you want to scan it? (yes/NO/selectively): Next adapter: AMDGPU DM aux hw bus 1 (i2c-5) Do you want to scan it? (yes/NO/selectively): Now follows a summary of the probes I have just done. Just press ENTER to continue: Driver `to-be-written': * ISA bus, address 0x290 Chip `ITE IT8655E Super IO Sensors' (confidence: 9) Note: there is no driver for ITE IT8655E Super IO Sensors yet. Check https://hwmon.wiki.kernel.org/device_support_status for updates. No modules to load, skipping modules configuration. Unloading i2c-dev... OK root@dipper:~# What I did in the temperature plugin: 1. Click "Detect". Field updates to "No drivers detected" 2. Tried typing "it87" in field, then click "Detect." "No drivers detected" 3. Tried typing "it8655" in field, then click "Detect." "No drivers detected" 4. Tried "it8655-isa-0920" in field, then click "Detect." "No drivers detected" 5. Tried uninstalling and reinstalling the plugin, then click "Detect." "No drivers detected" 6. Tried uninstalling, rebooting, reinstalling the plugin, then click "Detect." "No drivers detected" 7. Tried running `modprobe it87`, then click "Detect." "No drivers detected" I will try the `syslinux.conf` trick, but if that doesn't work I'll post in the temperature plugin thread. Thanks for the help!

Thanks for the reply; I just tried it but unfortunately it still cannot detect the driver. Any other ideas? Otherwise I'll wait for updates that might fix the problem.

@ich777 thanks for the reply. Great to hear mainlining is being worked on! The plugin does work and I'm able to see the sensors when I run `sensors`. The problem is the temperature plugin from Dynamix still says "No drivers detected" when I press the "Detect" button. Here's the output of `sensors`: it8655-isa-0290 Adapter: ISA adapter in0: 861.00 mV (min = +1.33 V, max = +1.40 V) ALARM in1: 2.52 V (min = +1.97 V, max = +2.19 V) ALARM in2: 2.05 V (min = +1.72 V, max = +0.28 V) ALARM in3: 2.03 V (min = +2.38 V, max = +0.63 V) ALARM in4: 2.03 V (min = +0.22 V, max = +0.32 V) ALARM in5: 1.94 V (min = +2.43 V, max = +2.75 V) ALARM in6: 2.03 V (min = +1.75 V, max = +0.28 V) ALARM 3VSB: 3.36 V (min = +1.40 V, max = +4.84 V) Vbat: 3.33 V +3.3V: 3.38 V Array Fan: 1776 RPM (min = 76 RPM) Array Fan: 1500 RPM (min = 43 RPM) temp1: +55.0°C (low = -77.0°C, high = -57.0°C) ALARM temp2: +47.0°C (low = -47.0°C, high = +28.0°C) ALARM sensor = thermistor temp3: +45.0°C (low = -9.0°C, high = +79.0°C) sensor = thermistor temp4: +45.0°C (low = -102.0°C, high = -25.0°C) ALARM sensor = thermistor temp5: +45.0°C (low = -74.0°C, high = -75.0°C) ALARM sensor = thermistor temp6: +45.0°C (low = +54.0°C, high = +11.0°C) ALARM sensor = thermistor intrusion0: ALARM k10temp-pci-00c3 Adapter: PCI adapter Tctl: +55.0°C amdgpu-pci-0800 Adapter: PCI adapter vddgfx: 1.38 V vddnb: 1.08 V edge: +45.0°C slowPPT: 4.00 mW Here's what the temperature plugin currently looks like once I press detect: The plugin does show the array fans (which is awesome by itself) but I'd like to get the processor and mainboard temperatures working as well if possible. I've tried typing in "it87", "it8655", and "it8655-isa-0920" into the "Available drivers" field and then pressing "Detect" again. It still results in the "No drivers detected" message. Any ideas?

@Frank Crawford thanks for the it87 driver! Is there any possibility of it shipping with the base UnRAID installation? Or being mainlined into the Linux kernel?

When connecting via a VPN, the IP is different than that of the local network. However, the Docker WebUI button uses the local network IP, which means it won't work. To fix this problem, take the HTTP_HOST header of the current session and append the port to it to open the WebUI instead. Some considerations: - Maybe the connection should be downgraded from HTTPS to HTTP in case the port does not support HTTPS traffic? - For the people who do not want this behavior, maybe a configuration option in Docker settings to open WebUI with the "original way"?

Didn't think of that; thanks for the easy workaround! EDIT: just tried this easy workaround and while it does work, it will throw up a one-time warning in the DFI plugin about mismatched hashes. It will update the hash after that so you shouldn't see this warning again.

You can manually set the extended attribute, although I do think this is quite the inconvenient workaround. Ideally the plugin should have a button where I can indicate that it was wrong, that the files are okay and it messed up. Anyway, once you find the file, run: getfattr -d <file> The command should return all the extended attributes of the file. Find the one for "user.sha256". Now generate a new SHA256: sha256sum <file> Copy the SHA256 hash, then type: setfattr -n user.sha256 -v <hash value here> <file> You may wish to re-run the `getfattr -d` command to verify that the update was successful. You may also need to re-run the export hash function inside the plugin.

Anybody know how to manually correct hashes for false positives? File Integrity keeps warning me about those files and I know they're okay – probably some sort of change that didn't affect the file change timestamp. I'd like to regenerate hashes for these files only instead of regenerating for the entire drive. Anybody know what command I'd have to run?

Great, thanks @JonathanM. I still can’t get the plugin to actually verify the hashes, and the logs don’t indicate any failure. Anybody manage to figure out why the plugin won’t verify the hashes?

Hi all, I'm trying to get this plugin to work on my server, but for some reason the "Check Export" button does nothing. It shows 0 completed, 0 failed, and just quits immediately saying the check completed successfully (which it obviously did not because the check finished in like two seconds). For some reason, the scheduled verification tasks work, but it's also broken as well, throwing up a ton of "corrupted" and "modified" errors, like below: SHA256 hash key mismatch (updated), /mnt/disk1/appdata/overseerr/settings.json was modified SHA256 hash key mismatch (updated), /mnt/disk1/appdata/overseerr/settings.json was modified SHA256 hash key mismatch (updated), /mnt/disk1/appdata/overseerr/settings.json was modified SHA256 hash key mismatch, /mnt/disk1/appdata/overseerr/settings.json is corrupted SHA256 hash key mismatch, /mnt/disk1/appdata/overseerr/settings.json is corrupted SHA256 hash key mismatch (updated), /mnt/disk1/appdata/Plex-Media-Server/Library/Application Support/Plex Media Server/Logs/Plex Transcoder Statistics.5.log was modified SHA256 hash key mismatch (updated), /mnt/disk1/appdata/overseerr/settings.json was modified SHA256 hash key mismatch (updated), /mnt/disk1/appdata/overseerr/settings.json was modified Each log contains about 2000+ of these "errors," mostly all within the appdata share. Is it just a false positive because of Docker messing with these files in the background? Should I just exclude the entire appdata folder in the settings?