Jump to content

TheGlitch

Members
  • Posts

    58
  • Joined

  • Last visited

  • Days Won

    7

TheGlitch last won the day on January 25

TheGlitch had the most liked content!

Recent Profile Visitors

200 profile views

TheGlitch's Achievements

Contributor

Contributor (5/14)

  • Dedicated Rare
  • Reacting Well
  • Collaborator Rare
  • Conversation Starter
  • One Year In

Recent Badges

31

Reputation

  1. Oh that makes more sense. lol I think the only way to solve this is too not bother encrypting things... lets just keep everything OPEN.
  2. I agree with @PsychoWards and @Todd Miller - we are having a conversation that plagues IT Security engineers all the time.... finding the middle ground of high security and protection but ease of use. Make things to easy and its not good protection. Make the protection as solid as possible and the user won't use it. The general standard dictates the data MUST be encrypted before it leaves the machine. The standard practice is you encrypt the data, and you store the keys in a Vault (like Bitwarden, 1Password, or a physical safe). HexOS is marketed to "prosumers" who want things to "just work." If HexOS forces encryption and the user deletes their OS without backing up the keys, the data is mathematically unrecoverable. Should we be storing keys on the HexOS servers? From a security standpoint, this COULD be a huge issue. The risk comes down to the possibility of HexOS getting hacked, the hackers then have the keys to everyone's backup. Buddy Backup aims to be a "zero-knowledge" system, and that should mean only the users have the keys. HexOS server can assist in the facilitation of passing the keys to each user because seeing part of the key isn't the actual key. They could use an identity-based key derivation like Steve Gibson's SQRL. If HexOS generated a Master Identity Key for each user, the system could automatically derive unique encryption keys for each Buddy Backup target. This would allow for 'Zero-Knowledge' offsite backups without forcing users to manually manage individual encryption keys for every dataset. We get the security of ZFS encryption with the ease of a single Master Password. In a SQRL-style system, if you reinstall the OS, you must have your Master Key backed up. If HexOS doesn't force you to save that master key (or the 24-digit Rescue Code) during setup, then a reinstall would mean the end of your data.
  3. So I noticed that HexOS requires encryption at the folder-creation stage for future offsite backups. Since Buddy Backup isn't out yet, how will the migration path look for users who have already populated large unencrypted datasets? Specifically: Will there be a built-in 'Migrate to Encrypted' tool to move data into a new encrypted dataset for Buddy Backup? Will Buddy Backup support 'Replication-level encryption' (encrypting the stream during transit/at rest on the destination) without requiring the source folder on my local NAS to be encrypted? What about application data folders that are already not encrypted, how would those be handled?
  4. I totally hear you on this. Alert Fatigue is a real thing AND a risk. If the dashboard is always red, you eventually stop looking at it, which is exactly when a second drive will fail. That said, please avoid disabling SMART entirely. It’s better to have a "noisy" warning than to be completely blind to a total disk collapse. Here is my take on how to handle this: The risky move is disabling SMART for the disk doesn't just hide the old errors... it stops the system from telling you if the drive starts developing new problems. The reality is HexOS/TrueNAS reports the drive as "Unhealthy" because the drive's own firmware has tripped a threshold. The OS can't "clear" a hardware flag that the disk itself is reporting. The advisement is instead of disabling the service, check the specific SMART attributes (like Reallocated_Sector_Ct). If that number stays static for a few weeks, you might be okay. But if that number is climbing, the drive is a ticking time bomb regardless of the data importance.... replace.... IT.... ASAP. I would recommend you run a long SMART Test. If it passes and the error count doesn't increase, you can sometimes manually tune the alert thresholds in the Disk Settings of TrueNAS to silence that specific error, while keeping the monitor active for new ones. Though that goes against every admin bone in my body. Stay safe with that data my friend.
  5. Sem problema, meu amigo, eu só queria ter certeza de que entendo o nível de NECESSIDADE vs. DESEJO. 😄 So I will be upfront, I am new to Nextcloud also, but I've read some of the documentation and have gleaned the following to your questions. Yes, it would seem ExApps need to un as their own separate containers. They don't run into the Nextcloud app itself. You do need a separate service called HaRP proxy to act as the bridge. Since HexOS is based on TrueNAS SCALE, you usually have to deploy HaRP as a Custom App using the the image found at, ghcr.io/nextcloud/nextcloud-appapi-harp:release. I did find this video helpful, maybe this could be your starting off point. I would highly suggest that you spin up some sort of sandbox environment to play around with. Not sure if forcing this rather messy setup into HexOS right now. Maybe in the future someone will develop an automation for it but... couldn't even guess when that could be. Sorry I don't have much to offer at this time. I'm not able to play around with Nextcloud to that depth until i get some other things figured out.
  6. Hey Bud, This is a common point of confusion with Nextcloud, as this is a new framework called AppAPI that was introduced to run "External Apps" (ExApps) for things like AI assistants and more advanced office integrations that run in separate Docker containers for better performance. For these to work, they need a "bridge" called HaRP (Homeland App Runtime Platform). If you are seeing the harp_proxy_host error, it simply means Nextcloud is looking for that bridge and can't find it. Do you need to use the ExApps or just wanting to play around?
  7. Check out https://wiki.serversatho.me/en/jellyswarrm
  8. Really good question and concern. It all comes down to... "How easy do you want your life to be?" lol You have a few options. Port Forwarding: Simple but higher risk. Switch to Emby: Simple and allows for remote users, but it would require a license. Reverse Proxy: Systems like Nginx / Traefik / Caddy - Best balance of security and usability VPN: Services like Tailscale but adds a little more complication on their end. You would also need to buy more slots (3 is free) unless you spin up Wireguard.
×
×
  • Create New...