Posts by Barney

Update to this issue: A very recent update removed the need to apply Chente's workaround (as described in post #9 in this thread.)

When this came up last spring, I apply Chente's workaround to one RPI NAS but left another one alone (no workaround.) I would do the dongle dance on this system as needed. My plan was to see if a subsequent update either fixed or reversed the change that led to this issue with USB-ethernet dongles. However I was not always disciplined to reboot after each update (especially when I wind up performing multiple updates in a short period.) Therefore I cannot identify the exact update where the issue behavior changed, but only know it was likely within the last 4-6 weeks.

Knowing the exact update is all academic anyway. I am simply reporting that I observed the boot behavior changed and we may no longer need the workaround.

Yes I ran into this too. I did a reboot and the issue went away.

I own that model and asked the same a year or so ago. Chente's answer is best. My follow-on is to say I really gave it a go and got myself into a situation where the thing bricked. Thankfully I was able to get it back to Synology but it wasn't easy. Also keep in mind that it only has 1 gig of ram so it's best to just leave is using DSM and setup SMB shares (which I have no problem accessing from either X86 (windows) or RPI (debian).

I noticed this the last few months too. Every time I initiate a backup, I wind up having to go back in and set "recursive" so all folders get backed up.

Actually noticed it reverted overnight again. I backed up last night setting recursive and today it's unchecked again!

Quote from sopvkore

I had the same (or similar?) problem after upgrading from OMV 6 -> 7. Graphs just didn't show up.

All services were OK, RRD database check was OK. Finally I tried to reinstall the rrdtools package and the problem disappeared.

apt-get install rrdtool --reinstall

Thanks mate, solved it for me!

Something I haven't seen anyone mention (or I missed it.) Generally a specific CMR model designed for NAS by Seagate has a 5 yr warranty and is covered for 24x7 operation. Conversely their SMR type drives that are generally the cheapest come with 2 yr warranties and there may be fine print that they won't be covered if they were run 24x7 (they can get the load/unload cycle counts from SMART.) I didn't see your model number but Google is your friend on this one.

I ran into something like this and found the controller was lacking full capability to pass SMART attributes. Contacted the controller company and their response was something like "we know, we fixed it in our newest model, buy that one." It's something to consider.

As the owner of two RPI4 running NAS boxes and OMV7, I am beginning to wonder how I got through all these updates (through yesterday) unscathed. No issues whatsoever. Sounds mostly ethernet id related and maybe those dang USB 2.5G dongles are actually working in my favor.

I'm interested to hear the issues. I have installed OMV countless times on three RPI4 and it always works fine out of the gate with various states of hardware. There have been occasions where an update might have a bug that was quickly fixed in a follow-up release. IMO the existing installation guide is perfectly fine and any attempt to add your own could wind up with people cloning any mistakes that is causing you headaches.

I'm noticing the same thing. Only it's the only drive on my system. I also notice the network performance is not getting logged.

By any chance are you using an ethernet USB dongle?

Can you change that ugly cable? Ribbon cables are so yesterday and not good for high speed transmission (if not laid out correctly.) I don't know what options exist though.

Quote from nurunet

I have ordered a different 2.5 GbE switch to see if that might be the cause.

I forgot to add that I think the issue is your switch.

Quote from BernH

Tradionally they have not performed as well as intel cards, and the fact the you still can't tweak their buffers continues to support that idea in my mind.

Yeah I'm not buying that you can't change the buffer setting. I've played with it before and noted that I could degrade the transmission speed. I'll revisit this.

Well I know what you are referring to but can't help you as I never archived the post. I'm interested in getting the workaround for my TR-004 as well.

Quote from BernH

I’d say it’s most likely a Realtek driver issue on Linux. Realtek cards usually don’t perform well on Linux. You may be able to improve it a bit if the driver supports adjusting its buffers.

I don't understand why there is a perception of Realtek drivers not working well under Linux. I have three systems with Realtek 8152, two are the much maligned USB dongles. I rail out the ethernet at 2.33 Gbps iPerf and even running through a 2.5G switch. The disc transfer from a Windows on SSD to an RPI4 with dongle will max out at 280 MB/s. I had played around with SMB buffer sizes in the past but noted no effect.

I can confirm there was an issue with Bullseye and OMV6 (stuck in half duplex) which did not allow maximum transfer but it's no longer a problem after Bookworm/OMV7. Maybe the problem statement is no longer valid.

I have the TR-004, which I have on a Win NUC that serves as a backup to my OMV based RPI. At one point I connected the TR-004 directly to the RPI and OMV had no problem seeing it as a single drive, even though I had the 004 setup in a hardware raid mode. What OMV won't allow is using it as a raid component along with other USB drives.

Any chance Jellyfin is trying to scan files to create it's library at first start? I ran into this after installing Jellyfin. It was such a CPU hog during this phase, I walked away from my system for a day and it was fine the next day.

FWIW, I have two installs. One is 7.3.0-3, which is good, it has the same bridge as the erroring install. The update that changed behavior is 7.3.0-4.. Weird I never saw it with 7.3.0-1 or -2.

Ah, I thought this update was very fresh so no one reported it yet (I just got notified by email today.)

Thank you!