SMART looks OK but doesn't look like an extended SMART test has ever been done on that disk.
This seems likely. From syslog it looks like a connection problem to me. You should always double check all connections, all disks, power and SATA, including splitters, any time you are mucking about inside.
Here are some relevant excerpts from syslog:
Oct 25 13:21:44 NAS kernel: sd 1:1:3:0: [sde] tag#37 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=9s
Oct 25 13:21:44 NAS kernel: sd 1:1:3:0: [sde] tag#37 CDB: opcode=0x88 88 00 00 00 00 00 38 26 11 50 00 00 00 20 00 00
Oct 25 13:21:44 NAS kernel: blk_update_request: I/O error, dev sde, sector 942018896 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942018832
Oct 25 13:21:44 NAS kernel: sd 1:1:3:0: [sde] tag#33 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=9s
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942018840
Oct 25 13:21:44 NAS kernel: sd 1:1:3:0: [sde] tag#33 CDB: opcode=0x88 88 00 00 00 00 00 38 26 0f 50 00 00 02 00 00 00
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942018848
Oct 25 13:21:44 NAS kernel: sd 1:1:3:0: [sde] tag#91 UNKNOWN(0x2003) Result: hostbyte=0x01 driverbyte=0x00 cmd_age=9s
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942018856
Oct 25 13:21:44 NAS kernel: blk_update_request: I/O error, dev sde, sector 942018384 op 0x0:(READ) flags 0x0 phys_seg 64 prio class 0
Oct 25 13:21:44 NAS kernel: sd 1:1:3:0: [sde] tag#91 CDB: opcode=0x88 88 00 00 00 00 00 38 26 0d 50 00 00 02 00 00 00
Oct 25 13:21:44 NAS kernel: blk_update_request: I/O error, dev sde, sector 942017872 op 0x0:(READ) flags 0x0 phys_seg 64 prio class 0
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942018320
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942017808
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942018328
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942017816
Oct 25 13:21:44 NAS kernel: blk_update_request: I/O error, dev sde, sector 942017840 op 0x0:(READ) flags 0x0 phys_seg 4 prio class 0
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942018336
...
Oct 25 13:21:44 NAS kernel: md: disk3 read error, sector=942011224
Oct 25 13:21:44 NAS rc.diskinfo[12723]: SIGHUP received, forcing refresh of disks info.
Oct 25 13:21:44 NAS kernel: md: disk3 write error, sector=942022904
Oct 25 13:21:44 NAS kernel: md: disk3 write error, sector=942022912
Oct 25 13:21:44 NAS kernel: md: disk3 write error, sector=942022920
Oct 25 13:21:44 NAS kernel: md: disk3 write error, sector=942022928
It looks like it may have been read failures that really started it. When Unraid can't read a disk it will try to write the emulated data back to it and if that write fails then the disk gets disabled.
It would be mostly guess work to say that the disk may not be very far out-of-sync if nothing was really writing to it and the emulated data is what was already on the disk.
If you want to take a chance, you could unassign the disk and then mount it read-only as an Unassigned Device to check its contents. If it seems to be OK you could New Config / Trust Parity. If it doesn't look OK then you could reassign and rebuild. In any case a parity check should be done, either to confirm it wasn't out of sync or to confirm the rebuild went well.
If you really want to take a chance you could even postpone that so you can use the server, but if anything is out-of-sync then rebuilding a real failure could be compromised.
Do you have good (enough) backups?