Issue closed: intended behaviour, won't fix.
I can't think of a worst act by a company that makes data storage devices than to intentionally and deliberately break data stored by their customers.
What a stupid and nasty action by a terrible company. They deserve to be sued into oblivion
I use a DS918+ at home which I got after having deployed Clustered RS units for VM storage in a previous role. The recent moves from the company (not certifying their devices with non first party hard disks, pushing more user licensed features (VPN/Email)) and a feeling that software quality is in decline (acknowledged bug in Apple TV app hasn't been fixed in at least 8 months).
It a real shame that both Synology seems to be following the ubiquiti route to smash their reputation to increase revenue.
This is an example of a stupid error that I can’t turn off.
They’re starting to assume that all devices are internet connectable and subject to brute force. That seems insane to me and my synology is on a private network with no inbound connectivity. I don’t want to change from admin.
Actual IT security is in depth, and the simple task of having an admin account that is not the default user ID makes sense to me.
What zero days are out there that rely on a known user ID, and a known process ID for that user’s first process? You could defeat that by just following the advice from people that know better.
If there’s a zero day ravaging my kids iPad then that’s the risk I take. And it’s acceptable given my situation.
“People that know better” for my situation seems pretty hard to qualify. I’m glad it makes sense to you, but since you have zero insight to my config and the changes required to implement I think it says more about the quality of your recommendations that you can give a recommendation without understanding the usability trade offs.
Maginot lines suck for protecting countries, but simple, clear defenses are pretty darn handy for protecting home networks. I’ll take a disconnected NAS over a wonderfully synced, fully compliant NAS following every recommendation (that also includes making it network accessible).
They refused to even look at the logs if I wasn't willing to give them root access to the primary system. I told them that wasn't an option but I was happy to provide any log they wanted and they just never responded to the case again.
Not sure if Synology has their ass covered via terms of service. Even if they did, it’s their fault people lost access to their data.
Interesting to see how this unfolds.
To get btrfs, you had to use another btrfs capable NAS and then move the drives over to use that unsupported functionality (which was, again not documented and clearly marked as unsupported) and this patch has now removed a module that allowed for accidental use of that unsupported functionality.
What legal grounds do you have here?
As a customer in Germany I sure hope the consumer protection agency (Verbraucherzentrale) could make them sing.
Synology provides no recourse, effectively bricking the device you own. See how Consumer protection agency likes that.
You being unable to access files miss out on some important work, or deadline. See how courts like that if you decide to bring a civil suit against Synology.
The problem here is that they actually did allow it, and did expose those settings.
Seeing that the GUI allows BTRFS, even if it was supposedly sold without support for it, might lead people to believe that the specs or documentation were outdated especially since the current documentation is actually outdated on many other matters and cannot be relied to 100% accurately reflect the current usage of the product.
Yeah, assume documentation is outdated. That makes sense.
Features change in software all the time.
What's so outlandish about someone getting a new unit, it upgrades the software automatically on first run, and then the BTFRS filesystem is available to them use for the array.
You'd either not think twice about it or thank Synology for opening up the new feature for these lower end units.
Taking the feature away like this is the absolute trashiest behaviour.
So your analogy should be "Car commercial showed a slow but practical car, you buy the car and it turns out to have high performance and can zoom around corners, then a year later a software update forbids you from driving on the road to your house that has a high speed limit so now you can't get home"
(I know btrfs on ARM wasn't really all that great at times.)
There is no "downgrade" path from btrfs to ext4. Users have to move all their data off the NAS to some other storage, delete the btrfs volume, create a new ext4 volume and then copy the data back on.
These alleged damages are measurable in both time and the cost of storage rental.
Even worse, if you apply this upgrade without knowing that you need to do this procedure, your data is inaccessible until you contact customer support.
Then six months later Tesla pushes out a software update overnight that removes that view and offers no way to restore the old one, or start your car, or unlock it.
Also, just for curiosity, and without condoning what the company is doing, is there a good reason to use btrfs for a device like that? I was thinking that good filesystem repair facilities are important once you store a lot of data, and btrfs is inferior to ext4 on this? I find btrfs is fantastic if you have, say, a bunch of Yocto images, or a large video you are working on, and you want to quickly create and erase snapshots of many gigabytes of data, but what is the advantage here?
No familiarity with these devices, but there is at least a slim chance if it was an embedded device, they needed the flash or RAM for something else. Seen this happen elsewhere before
Synology can easily allow access to the volume. I would think the smartest decision when removing a feature (even a feature that was never intended to exist) to instead make the unit at least mount the volumes as read-only and allow the data to be exported to the network / cloud / USB drive.
I don‘t want to be on any side. But is it wrong to fix a bug?