It started well ahead of actual BF, but Best Buy has 18TB Easystore drives for $200.

It would be nice if we, and apps’ developers, always knew what the vulnerabilities are. They generally exist because the developer doesn’t know about them yet, or hasn’t found a solution yet (though ideally has been transparent about that). Zero-day exploits happen. There’s always a first person or group discovering a flaw.

If being up to date and using SSL was all it took, security would be a lot simpler.

No one security measure is ever foolproof, other than taking everything offline. But multiple used in tandem make it somewhere between inconveniently and impractically difficult to breach a system.

It’s not. SSL in itself doesn’t make any exposed service safe, just safer. An updated service isn’t necessarilu free of vulnerabilities.

The difference between exposing your login page and most other services is the attack surface. If someone gets into your NAS administration, game over. You’re getting hit with ransomware or worse.

If someone gets into my Calibre Web server, for instance, my vulnerability is much more limited. That runs in a docker container that only has access to the resources and folders is absolutely needs. The paths to doing harm to anything besides my ebook library are limited.

I of course still use SSL, with my Calibre Wev behind a reverse proxy, with long complex passwords, and I’ll probably soon move it to an OATH login where I can use MFA (since it doesn’t support it natively itself). And there are more measures I could take beyond that, if I chose.

The login page to your NAS.

I’ve been playing with Joplin. The one thing I can’t decide if I like – there’s no web interface. You have to be using the app (versions are available for Mac, Windows, Linux and mobile devices).

There’s also Notes in Nextcloud.

If you’re happy with those services … maybe you shouldn’t?

I self-host because I prefer to house my data locally when possible. It’s easier for backups and I’m not subject to the whims and financial decisions made by a company about whether their service will remain available, what it will cost, what functions it will offer. The tradeoff is work on my part, but I enjoy tinkering and learning.

In my case, I self-host a NextCloud instance for remote access to my docs, a Calibre Web server for eBooks (and to share those with a few trusted friends), a Vaultwarden instance because I’d prefer my vaults not be stored by a company whose servers are likely a major target for bad actors and that could change its TOS or offerings in the future.

I installed it because I was curious, and still learning some things about Docker.

I pretty quickly used it to install portrainer, and I’ve since managed everything from there.

The file manager is moderately handy, but nothing I couldn’t do either with the command line or another filemanager tool I’d install through Docker itself.

I still have it set up because I have no need to change it, but I wouldn’t use it if I were doing my setup from scratch.

I’m kind of curious about Cosmos as what seems like a more comprehensive alternative, but I’m pretty happy with how I have some of its other functions (like reverse proxy) set up now, so if I try it, it’ll probably just be to tinker.

Thanks for the heads up on this project. It looks like it might work very well for some people who basically want a web app as a view right into a filestystem for dealing with folders.

Unfortunately, it doesn’t really meet the needs I’m laying out. The use case I’m describing is still one where the web app abstracts away the file system and uses albums. It just lays out a (smart, I think) way of recognizing and interpreting the organization in a pre-existing library, like one created from a Google Photos takeout, when bringing photos into its own system – accounting for duplicates in albums without doubling them up on disks.

Direct editing of EXIF is handy. Memories does that too, and it’s part of why it’s what I’m using. But my ideal situation would be one where the app only writes metadata changes to its own database initially, but then (optionally) applies it to EXIF when exporting/downloading files without touching the original files. And it would also give the user an option to apply metadata to EXIF for the original files, but only after first prompting with warnings.

It seems your design goals are pretty different than any of that – which isn’t a criticism, as I’m sure it works well for the way a lot of people like to work (just not me).

Syncthing would work well for just syncing.

So would Seafile, for a more Google Drive-like experience.

So would NextCloud, for more of an extensible Google Drive+Apps experience that you can customize to your needs.

Sorry, but this sounds a bit: “I’d like to eat this piece of cake, but also still have it available to me when I’m done.”

There are front-ends that can make docker apps easier to manage, like CasaOS. The tradeoff for ease of use is flexibility compared to something like Portainer or the CLI. CasaOS’s app library (for instance) frequently has out-of-date versions of apps, and if their default configuration doesn’t make sense for your purposes, you’re still going to have it delve deeper (whether in the CasaOS UI or another tool) to customize things to your needs.

That’s pretty much a given with any tool - if you don’t want to deal with how it works, then you need to accept the default configuration and cross your fingers that it works for your purposes.

And you’re still not going to get away from the fundamentals of how docker works, if you find them troublesome for some reason. Updating a docker app with something like CasaOS is doing the same thing it would be with Portainer or the command line. I’m not quite sure what seems “wrong” about it to you, but it would be “wrong” in the same way no matter what front end you use.