Howboys

Updated and now there's a few more vulns ("HIGH"): Description The version of Tomcat installed on the remote host is prior to 9.0.43. It is, therefore, affected by multiple vulnerabilities as referenced in the vendor advisory. - When using Apache Tomcat versions 10.0.0-M1 to 10.0.0-M4, 9.0.0.M1 to 9.0.34, 8.5.0 to 8.5.54 and 7.0.0 to 7.0.103 if a) an attacker is able to control the contents and name of a file on the server; and b) the server is configured to use the PersistenceManager with a FileStore; and c) the PersistenceManager is configured with sessionAttributeValueClassNameFilter=null (the default unless a SecurityManager is used) or a sufficiently lax filter to allow the attacker provided object to be deserialized; and d) the attacker knows the relative file path from the storage location used by FileStore to the file the attacker has control over; then, using a specifically crafted request, the attacker will be able to trigger remote code execution via deserialization of the file under their control. Note that all of conditions a) to d) must be true for the attack to succeed. (CVE-2020-9484) - An information disclosure vulnerability exists when responding to new h2c connection requests, Apache Tomcat versions 9.0.0.M1 to 9.0.41 could duplicate request headers and a limited amount of request body from one request to another meaning user A and user B could both see the results of user A's request. (CVE-2021-25122) - when using Apache Tomcat 10.0.0-M1 to 10.0.0, 9.0.0.M1 to 9.0.41, 8.5.0 to 8.5.61 or 7.0.0. to 7.0.107 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. (CVE-2021-25329) - A remote code execution vulnerability via deserialization exists when using Apache Tomcat 9.0.0.M1 to 9.0.41 with a configuration edge case that was highly unlikely to be used, the Tomcat instance was still vulnerable to CVE-2020-9494. Note that both the previously published prerequisites for CVE-2020-9484 and the previously published mitigations for CVE-2020-9484 also apply to this issue. (CVE-2021-25329) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.43 or later. ----------------------- Description The version of Tomcat installed on the remote host is prior to 9.0.63. It is, therefore, affected by a vulnerability as referenced in the fixed_in_apache_tomcat_9.0.63_security-9 advisory. - The documentation of Apache Tomcat 10.1.0-M1 to 10.1.0-M14, 10.0.0-M1 to 10.0.20, 9.0.13 to 9.0.62 and 8.5.38 to 8.5.78 for the EncryptInterceptor incorrectly stated it enabled Tomcat clustering to run over an untrusted network. This was not correct. While the EncryptInterceptor does provide confidentiality and integrity protection, it does not protect against all risks associated with running over any untrusted network, particularly DoS risks. (CVE-2022-29885) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.63 or later. ----------------------- Description The version of Tomcat installed on the remote host is prior to 9.0.40. It is, therefore, affected by multiple vulnerabilities as referenced in the fixed_in_apache_tomcat_9.0.40_security-9 advisory. - When serving resources from a network location using the NTFS file system, Apache Tomcat versions 10.0.0-M1 to 10.0.0-M9, 9.0.0.M1 to 9.0.39, 8.5.0 to 8.5.59 and 7.0.0 to 7.0.106 were susceptible to JSP source code disclosure in some configurations. The root cause was the unexpected behaviour of the JRE API File.getCanonicalPath() which in turn was caused by the inconsistent behaviour of the Windows API (FindFirstFileW) in some circumstances. (CVE-2021-24122) - While investigating bug 64830 it was discovered that Apache Tomcat 10.0.0-M1 to 10.0.0-M9, 9.0.0-M1 to 9.0.39 and 8.5.0 to 8.5.59 could re-use an HTTP request header value from the previous stream received on an HTTP/2 connection for the request associated with the subsequent stream. While this would most likely lead to an error and the closure of the HTTP/2 connection, it is possible that information could leak between requests. (CVE-2020-17527) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.40 or later. ----------------------- Description The version of Tomcat installed on the remote host is prior to 9.0.65. It is, therefore, affected by a vulnerability as referenced in the fixed_in_apache_tomcat_9.0.65_security-9 advisory. - In Apache Tomcat 10.1.0-M1 to 10.1.0-M16, 10.0.0-M1 to 10.0.22, 9.0.30 to 9.0.64 and 8.5.50 to 8.5.81 the Form authentication example in the examples web application displayed user provided data without filtering, exposing a XSS vulnerability. (CVE-2022-34305) Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number. Solution Upgrade to Apache Tomcat version 9.0.65 or later. There's more but it seems like these are still present.

Just skimming https://www.samba.org/samba/docs/4.15/man-html/smb.conf.5.html, the config in OP should continue to work as in 4.12.

M vulnerability scanner just popped up with this for DiskSpeed: Description According to its version, the remote web server is obsolete and no longer maintained by its vendor or provider. Lack of support implies that no new security patches for the product will be released by the vendor. As a result, it may contain security vulnerabilities. Solution Remove the web server if it is no longer needed. Otherwise, upgrade to a supported version if possible or switch to another server. Output Product : Tomcat Installed version : 8.0.53 Support ended : 2018-06-30 Supported versions : 8.5.x / 9.x / 10.x Additional information : http://tomcat.apache.org/tomcat-80-eol.html Seems like maybe it's time to upgrade Tomcat?

(unrelated to this issue but) I think that might have happened because preclear on USB3 ports seems to not work properly (-110 error code as you can probably see in the diagnostics I attached above). The pre-read happens for a couple of minutes at high speeds and then the device is just disconnected. Doesn't happen on USB2 so it's not the enclosure.

That's the only way? (I'll consider maybe doing preclears on my non-unraid server in the future as well)

I believe that's my tailscale network ip. And I removed sdj. I can connect it through SATA but the whole point of my USB enclosure is to check disk health before I open up my server. Is there a way to make unRAID "forget" sdj?

So I just got a USB enclosure to pre-clear and test drives before I put them in my unraid system. However, I have been unable to get it to work properly of late (the first 2-3 times I used it a month ago, I had no issues). I tried with a Samsung SSD first: Sep 11 11:51:56 Tower kernel: usb 4-2: new SuperSpeed USB device number 7 using xhci_hcd Sep 11 11:51:56 Tower kernel: usb-storage 4-2:1.0: USB Mass Storage device detected Sep 11 11:51:56 Tower kernel: usb-storage 4-2:1.0: Quirks match for vid 174c pid 55aa: 400000 Sep 11 11:51:56 Tower kernel: scsi host11: usb-storage 4-2:1.0 Sep 11 11:51:57 Tower kernel: scsi 11:0:0:0: Direct-Access ASMT ASMT105x 0 PQ: 0 ANSI: 6 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: Attached scsi generic sg9 type 0 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] 937703088 512-byte logical blocks: (480 GB/447 GiB) Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Write Protect is off Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Mode Sense: 43 00 00 00 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 11 11:51:57 Tower kernel: sdj: sdj1 sdj2 Sep 11 11:51:57 Tower kernel: sd 11:0:0:0: [sdj] Attached SCSI disk Sep 11 11:52:06 Tower emhttpd: device /dev/sdj problem getting id And then a different SSD: Sep 11 11:56:56 Tower kernel: usb 4-2: new SuperSpeed USB device number 8 using xhci_hcd Sep 11 11:56:56 Tower kernel: usb-storage 4-2:1.0: USB Mass Storage device detected Sep 11 11:56:56 Tower kernel: usb-storage 4-2:1.0: Quirks match for vid 174c pid 55aa: 400000 Sep 11 11:56:56 Tower kernel: scsi host11: usb-storage 4-2:1.0 Sep 11 11:56:57 Tower kernel: scsi 11:0:0:0: Direct-Access ASMT ASMT105x 0 PQ: 0 ANSI: 6 Sep 11 11:56:57 Tower kernel: sd 11:0:0:0: Attached scsi generic sg9 type 0 Sep 11 11:56:57 Tower kernel: sd 11:0:0:0: [sdj] Spinning up disk... Sep 11 11:56:58 Tower kernel: .ready Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] 488397168 512-byte logical blocks: (250 GB/233 GiB) Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Write Protect is off Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Mode Sense: 43 00 00 00 Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA Sep 11 11:56:58 Tower kernel: sd 11:0:0:0: [sdj] Attached SCSI disk Sep 11 11:57:02 Tower emhttpd: device /dev/sdj problem getting id I think the problem is that both drives are getting sdj but I'm not sure. Again, I've used this same enclosure with different drives in the past with no issues. tower-diagnostics-20220911-1157.zip

Did you ever figure it out? I also can't seem to get USB 3 ports on my mobo working right with the unraid flash drive, keyboard/mouse or a USB 3 HDD enclosure. USB 2 works fine but it's soooo slow.

Do i need the `/mnt/fuse/:mnt/borg` mount for the container? Fix Common Problems says borg should not exist in /mnt. These are the mounts I have:

Wow didn't know about this. Alright time to tweak shutdown settings (most likely it's just a ssh session that was open from one of my remote cron jobs).

Oh weird because I rebooted from the GUI. Should've been clean. tower-diagnostics-20220905-1754.zip

Alright rebooting the server has worked (though it started a parity check).

That's odd because the disk looks fine from smart. Here's the diagnostics. I won't reboot for a few more hours in case someone wants me to grab other logs. tower-diagnostics-20220905-0810.zip

Nothing happens when I click the "Clear Stats" button.