Here's the latest victory from the land of wallet-based elections: Synology, a leading maker of "network-attached storage" (NAS) devices, has done a quiet (but total) 180 on its enshittificatory policy of blocking third party hard drives from its products:
Network-attached storage devices are basically boxy computers with a bunch of slots for hard-drives and one or more network cards so you can connect them to your wifi or wired network. You fill them with hard-drives and plug them in, and they show up on your network as a file-server: any device on the network can connect to them and access their files. They're great for things like libraries of music or videos, which can be streamed to your TV or smart speakers. They're essential for people who work with very large files – musicians, photographers, video and sound editors, etc. They're also great for home backups, a single storage system that everyone in your household can back up all their data to. The better ones also have some kind of "NAT traversal" that lets you connect to them from the road – just plug your NAS into your home broadband and you can access your files from anywhere in the world.
Synology doesn't just make NAS boxes, they also make hard-drives that go inside them. Earlier this year, Synology pushed an update to its devices that caused them to reject hard-drives manufactured by their rivals, including giants like Seagate. This was a blatant piece of rent-seeking, a page straight out of the inkjet printer playbook, where the company that made the box decided that this gave them the right to decide what you could put in the box.
When your printer updates itself to reject generic ink, there's an implied threat: anyone who disenshittifies this printer – by making another update that restores generic ink support – risks prosecution under "anti-circumvention" laws like Section 1201 of the Digital Millennium Copyright Act. These are laws that ban reverse-engineering, even for lawful purposes, like restoring generic printer ink support:
The same goes for Synology. Under a decent and sane system of tech regulation, Synology's move to take away support for the vast majority of hard drives ever manufactured would prompt some other manufacturer to leap into the market and restore that support, by making alternative software for Synology's products. That represents a huge potential risk to Synology – once you're running a rival's software on your Synology product, it's a short leap to buying your next product from the company that saved your ass.
But because that kind of reverse-engineering is banned, enshittifiying companies like Synology don't have to worry about that kind of usurpation. They can enlist the justice system to destroy any company that tries to rescue us from their predatory behavior.
That leaves us with comparatively weak defenses against enshittification, like complaining in public, and/or buying someone else's products. These are much weaker than responses like "having a regulator fine Synology a zillion dollars for screwing us" or "having a rival company sell us a tool to disenshittify the product we already have."
Sometimes, though, those weaker measures really work. The hard drives that go in Synology's devices are fully standardized, and the data you store on them is far more valuable than the box you put them in. People in the market for a new NAS box can mix and match any hard drive with any NAS enclosure…except Synology's. That's a huge commercial disadvantage for Synology, and the fact that you can throw away your Synology box and keep your drives, and that any drive will work with any product except Synology, means that people really were able to vote with their wallets. After a catastrophic drop in sales, Synology pushed another software update that restored its support for every kind of drive.
Of course, no one should ever buy a Synology product again. They have shown us what they do when they have power over you and no one should ever give them any power over their economic future.
Remember, for enshittification to work, the company has to have locked in its users and/or business customers. Making things worse without some kind of lock-in simply precipitates a mass departure.
Contrast Synology' story with Chamberlain's. Chamberlain is a private equity-backed monopolist, a garage door-opener company that bought all the other garage door-opener companies, and then withdrew support for Homekit, a standardized way for apps to connect to home automation systems (like garage door-openers):
When Chamberlain nuked Homekit support, they forced every owner of every Chamberlain garage door-opener (which is basically all garage door-openers) to switch to using Chamberlain's app to open and close their garages, and now every time you open your garage, you have to look at seven ads.
Where Synology customers found it easy to switch vendors, Chamberlain customers are pretty stuck. Partly, that's because Chamberlain owns all the competing brands, so they are all defective in the same way. But also, it's because garage door-openers have to be installed, generally by a professional, and switching openers is an expensive, logistically complex operation. Of course, Chamberlain's app – like all apps – is off-limits to rival companies that might reverse engineer it to block its apps, thanks to the anticircumvention law's prohibition on reverse-engineering closed systems. Chamberlain's openers are also closed systems, which prevents rivals from reverse-engineering them and restoring Homekit integration.
It's interesting to compare Synology to other companies that enshittified, only to face a humiliating climbdown and blood on the C-suite's walls. There was Unity, the giant game-development tool monopolist who decided to institute a "shared success" program where they'd put a tax on any game made with their product that did well. Interestingly, they didn't want a "shared failure" program where they'd help defray the losses of any unsuccessful game made with their product. This is like the company who sold a hammer to the carpenter who renovated your kitchen demanding a share of the proceeds when you sell your house. After a mass revolt – including an industry-wide, very public switch to Unity's competitors – the company fired its top managers and abandoned its rent-seeking efforts:
Then there's Sonos, who remotely, irreversibly downgraded every smart speaker they'd ever sold in a doomed bid to create a unified app for the speakers and a set of headphones they were hoping to launch. The headphones fizzled, users were furious, and the CEO was defenstrated (but the speakers still don't work):
And earlier this year, HP, the world's most habitual and egregious enshittifier, climbed down from a breathtaking act of enshittification. The company announced that anyone calling for tech support would be put into a mandatory 15 minute hold, even if an operator was available to help out. The idea was to punish people for seeking help from a human, rather than making do with the much cheaper (and shittier) chatbot option.
People hated this and arose in towering fury, so intense that HP – world champion enshittifiers HP – backed down:
If only every company could be punished for enshittifying this way. If only, say, Reddit had gotten a suitable beat-down after its shameful attacks on third-party apps:
But Reddit is hard to leave. We might hate is asshole management, but we like each other, and so we hold each other hostage there because we can't agree on when to leave or where to go next.
Reddit enshittified, and so did Synology, and Synology's outraged (former) customers made them pay for it. It's one of those rare instances in which voting with your wallet actually works. Savor it.
If you'd like an essay-formatted version of this post to read or share, here's a link to it on pluralistic.net, my surveillance-free, ad-free, tracker-free blog:
Power Up Your Business Storage with Synology DiskStation DS1525+
5-Bay NAS | Secure Backup | High Performance
At Sanveer Infotech, we bring you the Synology DS1525+ — the perfect blend of power, scalability, and data security for your growing IT infrastructure.
AMD Ryzen Dual-Core CPU for blazing-fast operations
8 GB ECC RAM (expandable up to 32 GB)
5 Drive Bays with support for RAID 0/1/5/6/10
Built-in NVMe SSD cache slots
Snapshot Replication, VM Hosting & Centralized Backup
Ideal for SMBs, Creatives, and IT Professionals
Your Data, Always Protected
Your Storage, Easily Scalable
Ready to upgrade your storage infrastructure?
Contact Sanveer Infotech Pvt. Ltd. today for demo & pricing.
So in this world of rising streaming costs and license holders unilaterally deciding to pull content from streaming channels I figured I'd compile a few guides for people who want to cut those cords. As a rhetorical exorcise I'm going to list out some guides on how someone might want to create their own local media streaming service and how to automate management and supply of content to it. ALL RHETORICAL
I'm not going to explain how to build a media server, people who go that extensive won't need these guides, but if you have the cash, and don't want to build your own server you can always buy a higher end NAS from synology or QNAP that runs docker engine and you should be good.
Please make sure to follow the instructions for each individual guide in order depending on your choices. RHETORICALLY.
Newsgroups (you'll also need an account with a hosting service like Newshosting or Giganews as well as access to an indexer): https://drfrankenstein.co.uk/2021/07/30/setting-up-nzbget-in-docker-on-a-synology-nas/
Torrents (with this you'll need access to either public or private trackers): https://drfrankenstein.co.uk/2021/09/13/deluge-in-docker-on-a-synology-nas/
Then you install Jackett (this'll auto-manage all of your torrent trackers and create feeds for Sonarr and Radarr):
My horrible Odyssey to install Git LFS on my Synology NAS
So this is a bit different content from what I usually post. But I NEEDED an outlet for this incredible buildup of frustration that I had to deal with for the past WEEK.
The objective seemed easy when I decided to start this terrible journey:
Install Git LFS on a Synology NAS disk station.
The Status Quo
My friend and I wanted to work on a Unity project together, so "normal" Git, I was told, would not suffice. It had to be LFS. We looked into other options before, but I thought "Hey, why not use the readily available NAS I have? Why use external, even paid services if we can just use a homebrew solution?" And that's where the descent into madness started.
I have a DS418j, not the most advanced or expensive model. It is important to note that I went into this as a completely clueless person.
I never used Git via console commands. My knowledge of Git was generally very limited. Even at the end of all this, I still BARELY know how to set up a repository and interact with it.
I had no idea what LFS even really does.
I only had very rudimentary knowledge of how to operate my NAS via its user interface.
I never interacted with a Linux console before. It turned out that I would be doing that a lot.
A Walk in the Park?
At first, everything seemed pretty straightforward, to be honest. I googled the simple task of setting up Git on a Synology NAS. The first result was already pretty helpful.
It seemed like all I had to do was set up a new user on my NAS ("gituser"), also install the available "Git Server" from the NAS's user interface. And "WebDAV", another package that could be installed via the interface.
WebDAV, as I found out, was a key component in my journey. It was a bit of a struggle to set up, but it appeared to be important in the process of connecting to my NAS via HTTPS. And probably other things that I still have no idea about.
I didn't even know why I'm installing WebDAV in the first place, because I intended to use Git via SSH. Which another setting in my NAS would provide - the Terminal setting in the system settings. That's where I enabled SSH via port 22.
Well, my friend then told me that we cannot use LFS via SSH. Okay, I thought, that's what WebDAV is for, after all.
The Git Server had very few options, which seemed fishy to me. It literally only has one window where you set permissions for users. I gave gituser the permission to access it. That was that.
Of course I also needed a shared folder for our repositories ("git"). Creating that was not hard either. Here I noticed that gituser needs to be part of the "administrators" group for Git Server to work properly. But I could not remove it from the "users" group, so things got a bit fucky with permissions. I ended up giving both the administrators and users group a lot more permissions than I was comfortable with. But I trust my friend to not wreak havoc on my NAS for the time being.
So, everything was set up. Or so I thought.
Hitting the first Bump in the Road
I was able to connect to my NAS via SSH only, but didn't think anything of it yet. Doing that, I used Sourcetree to create the first test repo. Went to the NAS interface, checked, it was there and looked good. I could push and pull files.
Created a second repo, ran "git lfs install"... and it didn't work.
The lfs command was not known.
I quickly found out that... of course it could not be known. Other than github for example, my NAS did not have LFS pre-setup. So, I concluded, I had to go install LFS on my NAS.
...Easier said than done.
While it does support a console with most regular Linux commands... a package manager is not included. At least none that is easily accessible, or supports any common packages.
At this point I figured "Why deal with this myself?" and contacted Synology support. I asked them "how can I set up Git LFS on my NAS?"
And Synology Support said:
¯\_(ツ)_/¯
They told me they do not offer support for the console. They said I should go ask the community. Okay.
I did not ask the community, but I did a lot of googling and found out: I could not "just install" LFS. I had to get creative.
We heard you like package managers?
First, I figured out that I need to be able to use the "curl" command. All the binary files on LFS's package cloud were binaries that were apparently downloadable with curl. I did not know what curl was... but I knew I needed to get it working.
I found out that for curl to work, I needed to install PHP on my NAS. Luckily, that was possible via Synology's included package manager. But for PHP to DO anything, I also had to install the "Web Station" and configure my PHP version there. I figured... might as well!
After enabling a couple PHP commands, I felt ready to download LFS. But the question was... which version? What even was my OS?
As it turns out, Synology uses a custom Linux version for their diskstations. Of course, LFS does not "officially" provide a package for that version. I tried the nodeJS version, because I noticed I also have nodeJS installed on my NAS.
I ran into the version issue as well, unfortunately, when I tried to install the package through nodeJS. Not even changing my nodeJS version helped. Many hours later, I tried the .deb and .rpm files randomly instead of the nodeJS ones. Those also didn't want to work, despite me eventually figuring out how to lie to them about which OS I'm using.
I was almost ready to give up at that point. I was at least 3 full days into my odyssey already.
But then I spotted something else... A thing called "GoLang". Apparently, it would be possible to download LFS via GoLang. However, to do that, I of course needed to get Go first.
An initial search got me on track to "ipkg", which promised to enable me to install Go. But after reading up on it a bit, it looked woefully outdated. I had it already downloaded and was about to install, but ran into errors and trouble again.
That was when I found "Entware". It's similar to ipkg, but uses "opkg", a similar package manager. I was able to install Entware on my NAS without much trouble, and it contained the Go package that I needed so direly.
While I was at it, I also installed the available "git" and "git-http" packages from opkg, just to make sure. Who knew if they'd come in handy. I don't know if they did, but they also didn't seem to cause any harm.
Now, with Go installed (which went surprisingly smoothly), I was able to access just about anything on the internet and install it on my NAS! Hallelujah!
But if you thought it was over... just look at the scrollbar.
The end of my odyssey was finally in sight. I thought that nothing could go wrong anymore, now! With the help of Go, I was able to install the LFS binary. I was able to run it in my console, too. I was finally able to run "git lfs install".
...and it didn't help.
I got a bunch of errors, again. Instead of getting closer to the solution, it seemed like I just managed to find more obscure errors.
Here the important thing about the SSH came in, as well. LFS does not like SSH, from what I found out. But SSH was the only way for me to connect to my NAS from my PC!
In a fury of looking up stuff again, I found the "DDNS" option on my NAS. That would allow me to get a hostname and use it like a normal website address! I kinda rushed through the setup because I had no idea what I was doing.
Well, whatever I did, it seemed to be sufficient. My friend could now connect to my NAS over her Sourcetree client. But when she tried to upload LFS objects, it just didn't work. She got a "404" error.
It wasn't hard to figure out that 404 meant no access in this case - my NAS was simply refusing to show any directory to someone who doesn't have access to it.
Cue a long journey into my NAS's interface to make sure the gituser had the right permissions. I also changed the password because I read something about WebDAV being particular about some passwords. I also made a new user to see if maybe I just messed up setting up gituser.
To test if I was making any progress, my friend and I tried to access my NAS via our web browsers. But no matter what we tried, no matter what I tried, we couldn't access. 403 Forbidden or 404 Not Found. Those were the results. I couldn't even access if I used my admin account.
I tried to hack my way into pushing anyway, and only ended up corrupting our repo's history with "missing" and "broken" files because they were never properly uploaded, but LFS thought they were.
It should be noted that I had just accepted that HTTPS won't let me connect on my PC. So I had set up a hotspot for my mobile internet via my phone and used my laptop to do these things. I was in denial about eventually having to fix this, because I'm on a tight data plan on mobile and uploading and downloading Unity projects of several GB size wasn't going to happen that way.
Synology Support to the Rescue! ...Or?
It seemed like we had finally narrowed down the issue with our LFS upload attempts when I also checked the WebDAV console and it reported that it denied our login attempts through browser and Sourcetree as an "authorization failure".
So something was wrong with WebDAV.
I contacted Synology support a second time. I asked them, "Why can't my friend and I connect to my NAS via the internet when I have WebDAV enabled and everything port forwarded?"
And Synology Support said:
¯\_(ツ)_/¯
They told me WebDAV and web browsers don't use the same HTTP and HTTPS methods. They are simply not compatible. They told me I should download their WebDAV client or connect locally.
So it was known from the start that what I was attempting could never work... but it was also not mentioned anywhere on the web or Synology's help pages that this was the case.
We have a saying in Austria: "jemanden deppert sterben lassen". It translates to "to let someone die stupid". Essentially, it means that you have information and you watch someone else without this information struggle without ever telling them about it voluntarily. I felt this saying was very appropriate for my situation.
Time to give up, I guess... Except I didn't.
I was almost a week into my odyssey by now. Maybe it's a sunk-cost-fallacy, but I couldn't abandon all my work now. I refused.
A Light at the End of the Tunnel
I went back to open another browser tab (my average was 20 open tabs during this... normally it's 2 to 3). And I searched for a solution that works with WebDAV. And truly... there was ONE repo online that offered it.
A special thanks goes out to this fellow: https://github.com/mpotthoff/git-lfs-webdav
They straight up saved our project from collapsing into a pile of tears and rage.
I installed this package on my NAS, which... sort of worked. It turned out I needed to install it locally (as well?). So I did. But I needed to install Git, LFS, and Go on my local PC as well for that.
So with the help of Go, I built an exe file for my laptop, which then gave me a 401 when trying to push to LFS. Luckily I expected that. And I was overjoyed, because FINALLY a different error.
I tried to run the steps in the git-lfs-webdav repo to fix it... but got a strange error in the console.
It cried, when trying to enter my username, that the "handle" for the password was wrong. But I hadn't even entered the password yet!
Searching some more on the internet gave me no conclusive answer. Randomly, I tried a different console - my Sourcetree console apparently runs "MINGW32" while my Git console runs "MINGW64". Switching to the Git console fixed this problem for me, and switching to the Windows shell fixed it for my friend.
And then, it finally worked for my friend.
She could upload a test image via LFS, and I could receive it via LFS on my laptop.
The rest was me calling my internet provider about my PC being unable to connect. The internet provider said ¯\_(ツ)_/¯.
Luckily I did not attempt to mess with my DNS or Subnet Mask or anything of the sort, or buy a VPN/Proxy. All I had to do was create a self-signed SSL certificate on my NAS, download it, and feed it into my PC's trusted authorities files. My friend had to download and feed it too.
In Summary...
This was a horrible, terrible, awful journey. I would not recommend attempting this at home to anyone.
Even now, what we've got going on only sort-of works with our Unity project, because Unity is... Unity. We're still figuring out the details, for example why scene content is going missing and so on.
But I believe that the worst and most difficult part is over. Will I be able to recreate this in a year or two, maybe for a different repo, on a different PC?
