The only thing worse is the tone deaf customer service responses. Such as: - Wanting root SSH access to someone's device to investigate? - Suggesting getting a higher spec Synology device would be able to fix the problem

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.

Oh I hate that “grant access” so much, at least to date they have never pushed back when I’ve said no thank you and it’s not been required

You must have lucked out. I tried getting them to fix hyperbackup issue and sent them detailed logs of exactly what was breaking and how. It wasn't honoring the port setting from what I recall.

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.

At the same time the security advisor in Synology DSM spams you with notifications to disable the admin user account after creating another account with admin rights first

I’ve used synology for 10 years and really liked them. But there’s quite a few annoying things popping up more frequently.

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.

Your Maginot line is only providing imaginary security.

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.

I’m not trying to provide absolute security as it’s for my home network.

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).

Isn’t there a Config page somewhere the let’s you pick what warnings to show?

Not that I’ve found through searching their docs and walking through the UI, but I haven’t really dig deeply into the internals.

If Synology doesn’t resolve this PR drama soon, affected customers should indeed try the legal route.

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.

What kind of legal route is there though? The NASes were explicitly sold without support for btrfs (when I was looking at options, they were clear about that). They explicitly did not allow creation of btrfs arrays and did not expose any settings related to them.

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?

> They explicitly did not allow creation of btrfs arrays and did not expose any settings related to them.

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.

Oh, so all those car commercials of a normal econobox showing high performance, zooming around hairpin turns - I should expect that from my own car because it was in the commercial?

Yeah, assume documentation is outdated. That makes sense.

I don't know what your issue is apart from maybe being a Synology shill.

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.

Your analogy is all wrong, since they advertised these as NOT supporting BTRFS, but they did anyway.

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 still don’t think the analogy captures the reality of the situation. I’d argue it’s more like buying a car that advertised room for five passengers, but when it’s delivered your discover a third row giving you enough room for your entire family of seven. Until you take it in for an oil change, when they lock your kids in the trunk and try to sell you an SUV.

There's an underlying assumption that btrfs support on those devices was actually production level stable and ready for use.

(I know btrfs on ARM wasn't really all that great at times.)

How horrible it would be if commercials had to be truthful.

There's a theory that all adverts, that are not simply information are economic loss. This presumes that vanity has no economic value. How can you legislate when people want to be lied to.

A few people seem to have confirmed this isn't actually true - at some point, it was possible to set up at least some of the affected NAS devices using btrfs via the standard GUI on the device. It's possible there were some intermediate software releases which disabled that but still allowed existing btrfs volumes to be used.

The way they have gone out of their way to deliberately remove the functionality could be argued to cause damages to people who are using the unsupported functionality.

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.

Wasn’t supported. There’s no standing here. If I find out my Tesla can change traffic lights for me due to a bug, and then Tesla fixed the bug, it doesn’t mean I get to sue Tesla for that.

Nope, this is like if higher models of Teslas had a more in-depth mode on the display for a couple of years. When you first buy your lower model, during the on-boarding process with the dealer, they walk you through the setup process and ask if you'd like the standard view or the more detailed one. You say you want the more detailed one.

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.

Sue them for damages and see what sticks. Causing data loss like this is inexcusable.

As a customer in Germany I sure hope the consumer protection agency (Verbraucherzentrale) could make them sing.

Way too technical, will never get anywhere. Have better backups and don’t play cute games with important data storage.

No, the outcome is really simple. You had your DS420j humming along yesterday, then this DSM update comes around and installs overnight, and this morning you have no access to your files.

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.

Judge: Where's your backup?

Is there any technical reason why it is not supported?

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?

These "j" devices have like 512 MB of RAM and an ARM CPU. I believe the devices they do support BTRFS on all have 1-2 GB+ RAM and x86 CPUs.

Then how come it did work before? BTRFS as used in DSM is not particularly more memory intensive than EXT4 (which is why it did work before).

It works, but there is a risk (exacerbated if you use other features) that the device will become unstable. I believe depending on features used in btrfs it can use considerably more RAM for caching filesystem structures. While this cache can be freed, performance drops as the system need to retrieve this from the disk again. Considering reliability / reputation / performance it makes sense to not allow it as a supported configuration. However many vendors do this softly, and not as a hard lock. i.e. we won't let you create it (or we do and warn you), but if you complain / log a support ticket it will be ignored until you can show it on a supported configuration.

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 think it's RAM, not CPU. My DS418 has 2GB of RAM and an ARM CPU and supports BTRFS.

Compare that to the 4GB of a Raspberry Pi 400.

We already store a lot of data at home. And ssd and hdd storage has sometimes read errors. With terabytes of data we come across a handful error s per year, most of them will nobody notice. I use btrfs everywhere I can and see sometimes errors, most times on heavy written files like databases(sqlite files) or virtual harddisks, sometimes even pictures or logfiles. Even without RAID you could restore the file from a backup (If you try to backup a broken file, the computer won’t let you).

> Is there any technical reason why it is not supported?

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

Not enough RAM, possibly the CPU they chose wasn’t fully tested.

Is it? They explicitly did never support the fileysystem on the mentioned device and it was only possible because of a bug in their implementation.

I don‘t want to be on any side. But is it wrong to fix a bug?

Seems like it was a marketing bug ("spec says: only provide this feature for people who paid us more money", implementation says: "everyone gets this feature"), but the "fix" is for the affected people to move everything out of the affected devices, reset them, and copy the data back.

Legal ransomware. Nice.