Yea, I don’t think the se runs it out of the box but I’ve heard an rpi can be used

I got the se a couple months ago, unfortunately it doesn’t use klipper without modding it with a rpi as far as I know

Thanks, corrected my comment above.

I’m interested in ksmbd… I chose SMB simply because I was using it across lunix/windows/mac devices and I was using OMV for managing it, but that doesn’t mean I couldn’t switch to something better.

Honestly though, I don’t need faster transfers typically, I just happen to be switching out a drive right now. SMB through OMV has been perfectly sufficient otherwise.

SATA III is gigabit, so the max speed is actually 600MB/s.

My mistake, though still, a 4tb transfer should take less than 2hr at 5Gb/s (IN THEORY) Thank you @Max_P@lemmy.max-p.me for pointing this out a second time elsewhere: 6Gb/s is what the sata 3 interface is capable of, NOT what the DRIVE is capable of. The marketing material for this drive has clearly psyched me out, the actual transfer speed is 210Mb/s

The filesystem is EXT4 and shared as a SMB… OMV has a fair amount of ram allocated to it, like 16gb or something gratuitous. I’m guessing the way rsync does it’s transfers is the culprit, and I honestly can’t complain because the integrity of the transfer is crucial.

I’m a Linux/selfhosting novice, but from what I understand, Linux (and proxmox) uses intelligent resource management. It should adjust CPU and memory demands between tasks and VMs. My small stack of VMs running a media server and omv is basically always redlining with memory, occasionally with cpu (I don’t have a dedicated GPU for encoding though)

The storage is a different problem, but it doesn’t surprise me that Lemmy would use quite a bit of storage with active federation and multiple users.

My understanding is that it’s a combination of correctly deploying authentication (DMARC, DKIM, and SPF) and the actual IP address of the server that can get you into trouble. If you incorrectly set up authentication, OR if a malicious sender spoofs you (likely because you didn’t set up auth correctly), it can get your IP blocklisted. And unless you’re monitoring if you’re blocklisted, you often don’t know that things aren’t getting delivered until someone tells you.

And then you’re still kind of at the whim of the big players, because they could change or update their authentication standards, and if you’re not on top of it you can find yourself in the same boat, even if you’re doing everything else right.

It’s not impossible, it’s just a headache. But if i’m being honest, i’m a bit of a novice so it could be easier to a more trained network administrator.

I edited the comment, I really meant hosting server, not domain.

Having a custom domain isn’t a big deal, it’s really where that domain is hosted that creates forwarding issues. Since the majority of email is handled by the ‘big three’, anything that’s hosted outside of that is often flagged as spam or is refused to be delivered. That’s allegedly because there are malicious senders also hosted on third party servers (and fair enough, there likely are), but this causes a bit of a potential monopoly that could easily be abused, and there’s obvious motivation to push people into a particular service for data collection.

Even if it doesn’t happen often, occasional failures can be a huge problem if you’re sending critical communication and it isn’t reaching target inboxes because of filtering. It’s enough of a headache that even most avid self-hosters tend to avoid it.

I’m curious about this too.

A lot of self-hosted FOSS people draw the line at hosting their own mail servers. Even if Mozilla created a new domain hosting server for handling, the big three could still reject the traffic like they do for people hosting outside the three now, under the guise of spam filtering.

I’d be ecstatic if they did something here, but I’m not really clear on what a solution would look like. On top of them spreading thin as you mentioned

*edited ‘domain’ service to ‘hosting’ service

actually I think i’ve identified an issue with the original SSD. Here’s the readout to sdb, which i was just having more issues with:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  5 Reallocated_Sector_Ct   0x0032   100   100   ---    Old_age   Always       -       0
  9 Power_On_Hours          0x0032   100   100   ---    Old_age   Always       -       2050
 12 Power_Cycle_Count       0x0032   100   100   ---    Old_age   Always       -       11
165 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       4194345
166 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
167 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       159
168 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       1
169 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       1859
170 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
171 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
172 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
173 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       0
174 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       6
184 End-to-End_Error        0x0032   100   100   ---    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   ---    Old_age   Always       -       105
188 Command_Timeout         0x0032   100   100   ---    Old_age   Always       -       0
194 Temperature_Celsius     0x0022   074   049   ---    Old_age   Always       -       26 (Min/Max 22/49)
199 UDMA_CRC_Error_Count    0x0032   100   100   ---    Old_age   Always       -       0
230 Unknown_SSD_Attribute   0x0032   001   001   ---    Old_age   Always       -       34359738376
232 Available_Reservd_Space 0x0033   100   100   004    Pre-fail  Always       -       100
233 Media_Wearout_Indicator 0x0032   100   100   ---    Old_age   Always       -       1773
234 Unknown_Attribute       0x0032   100   100   ---    Old_age   Always       -       1852
241 Total_LBAs_Written      0x0030   253   253   ---    Old_age   Offline      -       1787
242 Total_LBAs_Read         0x0030   253   253   ---    Old_age   Offline      -       9876
244 Unknown_Attribute       0x0032   000   100   ---    Old_age   Always       -       0

that’s good to know, thanks.

i figured it was bottom barrel, i hadn’t really heard of the brand and it was a bottom-barrel priced referb

this came back clean, though the drives did not have smart reporting enabled. looks like the ata controller or some component between the cpu and sata bus is removeded.

I think this is it. Checked memory with memtester, came back clean. Switched to a different ata port, started a read-write using badblocks, and i was flooded with I/O errors, even on the new port and with a fresh disk wipe.

Looks like i’ll be looking for a replacement. Thanks for the suggestion, as painful as it was!

they are all sata 3 internal hard drives. I just swapped the sata port that was having the problems, and so far the testing has been looking good. I have been worried, though, that the psu isn’t big enough, or that the cabling is too old (they are old-school color-labeled and relatively thin compared to my desktop’s). it should be fine though, since the specs say it supports up to 4 drives (including optical)

edit - the tests did NOT go well. read-write on a different sata port produced the same errors.

this is looking like a likely scenario, thanks for the suggestion!

i’m going back and looking, but I may have deleted logs for the VM’s when I deleted the VM and started repair.

here’s a readout of one of the instances of trying to shutdown the VM and having to ssh in and ‘force’ a shutdown (didn’t think i was forcing it from the terminal window, but maybe I did?) Doens’t give much more information.

/var/log/pve/tasks/D/UPID:pve1:00000AD5:0000AEFC:652DD26D:qmshutdown:110:root@pam::TASK ERROR: VM quit/powerdown failed - got timeout

i’m still looking for more detailed logs, but i’m starting to wonder if you’re right. This makes me more sad than having messed something up myself, because fixing it would involve buying more hardware :(

oop, just found some better ones in the journalctl. These were happening way earlier than I thought:

Oct 13 17:28:42 pve1 kernel: SMB2_read: 36 callbacks suppressed
Oct 13 17:28:42 pve1 kernel: CIFS: VFS: Send error in read = -5
Oct 13 17:28:42 pve1 kernel: CIFS: Status code returned 0xc0000185 STATUS_IO_DEVICE_ERROR
Oct 13 17:28:42 pve1 kernel: CIFS: VFS: Send error in read = -5
Oct 13 17:28:42 pve1 kernel: CIFS: Status code returned 0xc0000185 STATUS_IO_DEVICE_ERROR

there’s a million of these.

and here are some of the one’s i was seeing when I popped open the console while it was happening. pve1 was the mount device to the VM running the OMV server I think:

Oct 14 23:14:14 pve1 kernel: I/O error, dev sdb, sector 1801348384 op 0x0:(READ) flags 0x1000000 phys_seg >

and a bunch of these, looks like they happen after a lot of I/O errors happen and the system can’t reach the smb server anymore:

Oct 16 13:25:04 pve1 kernel: CIFS: VFS: \192.168.0.135\plex_media BAD_NETWORK_NAME: \192.168.0.135\plex_media

Here’s ones from yesterday, probably around the time i was getting the new HDD back up again. These call out the sata port specifically, and it’s running repeatedly in a loop:

Oct 18 21:52:22 pve1 kernel: ata4.00: configured for UDMA/133
Oct 18 21:52:22 pve1 kernel: ata4: EH complete
Oct 18 21:52:22 pve1 kernel: ata4.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 18 21:52:22 pve1 kernel: ata4.00: irq_stat 0x40000001
Oct 18 21:52:22 pve1 kernel: ata4.00: failed command: WRITE DMA EXT
Oct 18 21:52:22 pve1 kernel: ata4.00: cmd 35/00:a8:00:38:ff/00:00:27:01:00/e0 tag 18 dma 86016 out
                                      res 51/04:a8:00:38:ff/00:00:27:01:00/e0 Emask 0x1 (device error)
Oct 18 21:52:22 pve1 kernel: ata4.00: status: { DRDY ERR }
Oct 18 21:52:22 pve1 kernel: ata4.00: error: { ABRT }

and here’s some more implicating the sdc device:

Oct 18 21:57:23 pve1 kernel: sd 3:0:0:0: [sdc] tag#25 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_OK cmd_age=2s
Oct 18 21:57:23 pve1 kernel: sd 3:0:0:0: [sdc] tag#25 Sense Key : Illegal Request [current]
Oct 18 21:57:23 pve1 kernel: sd 3:0:0:0: [sdc] tag#25 Add. Sense: Unaligned write command
Oct 18 21:57:23 pve1 kernel: sd 3:0:0:0: [sdc] tag#25 CDB: Write(16) 8a 00 00 00 00 00 e8 c4 08 00 00 00 00 08 00 00
Oct 18 21:57:23 pve1 kernel: I/O error, dev sdc, sector 3905161216 op 0x1:(WRITE) flags 0x1008800 phys_seg 1 prio class 2

There are actually kind of painting a picture. The culprit looks like that sata port, i’ll see if i can switch it to another and do some test writes, maybe that’ll fix it

But that’s doesn’t just appear from nothing.

Yea I think that’s kinda their point