As a small homelabber I agree with this. I started with a baremetal and using Docker, and switched to Proxmox, and now over to Incus, actually currently I am using Debian with cockpit + cockpit-machines. I do like Incus, I keep hopping back and forth between cockpit, I need to settle on one.

It’s a relatively low performance hit and it benefits me when having to replace a failing/old disk. I can just toss the drive without having to erase the data first, that is as long as the key is a secure length.

It is very useful! It’s also slightly customizable in that you can have it not save duplicate commands.

More information can be found on the Arch Wiki or the man page

~53 W

• Server:

  • AMD Ryzen 5 5600G
  • 4x16 GB DDR4 3200 Mhz
  • 256 GB NVMe as boot-disk
  • 2x256 GB Samsung SSDs for VMs
  • 2x2 TB WD Red Plus HDDs

• Mini PC: Beelink S12 N95

  • 16 GB DDR4
  • 256 GB NVMe

• 8 port unmanaged TP Link switch

I would like to expand my storage, however I don’t have any available SATA ports and I believe adding an HBA would increase the idle draw about 8 W. I might just upgrade the SSDs and split the storage between the HDDs and SSDs.

I recently switched from Proxmox to Debian Bookworm with Incus(LXD fork) as my primary setup, it’s been a pleasant experience. I also like the idea of using something like Cockpit to manage VMs though haven’t come to a need yet for a VM over a container. I’ll also point out that Incus can handle VMs as well.

Stéphane Graber, Project leader of Linux Containers is also on the fediverse and responds to questions often.

That’s a good recommendation, thanks!

There’s even an RSS feed for that page: https://openwrt.org/feed.php?mode=list&ns=advisory

You’re welcome! Also thanks for asking this question, I hadn’t seen ShotShare before, it looks useful.

No, since you are using the bind mount, you do not need to use the volume.

I just did another test.

You should be able to create the directories manually. I cheated by simply cloning the repo and copying them to the bind mount location like so. You can use the bind mount method like you wanted.

git clone https://github.com/mdshack/shotshare
cp -r shotshare/storage/* /srv/dev-disk-by-uuid-7fe66601-5ca0-4c09-bc13-a015025fe53a/Files/Shotshare/shotshare_data/
chown 82:82 -R /srv/dev-disk-by-uuid-7fe66601-5ca0-4c09-bc13-a015025fe53a/Files/Shotshare/shotshare_data

It will be stored in /var/lib/docker/volumes, you can find the exact location by inspecting the volume. Use docker volume ls to list the volumes, and do docker volume inspect <volume_name> replacing <volume_name> with the one from the list. Look for “Mountpoint”, that is the exact location. You could try copying that to bind mount location, though I can’t be sure if it will continue to work.

This appears to be the exact same problem as https://github.com/mdshack/shotshare/issues/31

For testing I just spun up a VM with Docker, I tried the same compose file as you. I found I had to use the volume instead of a bind mount for /app/storage.

This compose file should work.

version: "3.3"
services:
  shotshare:
    ports:
      - 2000:80
    environment:
      - HOST=:80
      - ALLOW_REGISTRATION=false
    volumes:
      - shotshare_data:/app/storage
      - /srv/dev-disk-by-uuid-7fe66601-5ca0-4c09-bc13-a015025fe53a/Files/Shotshare/database.sqlite:/app/database/database.sqlite
      - /srv/dev-disk-by-uuid-7fe66601-5ca0-4c09-bc13-a015025fe53a/Files/Shotshare/.env:/app/.env
    restart: unless-stopped
    container_name: shotshare
    image: mdshack/shotshare:latest
volumes:
    shotshare_data:
networks: {}

That error message says it the permissions of the /home/user/Documents/Docker/LinguaCafe/logs directory. You can try changing it full r/w temporarily to test.

I like it, then it’s even harder to know that it was encrypted in the first place. Thanks for that suggestion.

While this wouldn’t work for you now, something to think about is encrypting new drives going forward so that you don’t have to worry about erasing/zeroing them, just toss the encryption key and your good to go.

I just spun a container up to test this, it disables the registration and only allows invites after the initial account has been created, it returns an error if someone accesses the registration page and tries to create an account, https://www.focalboard.com/guide/server-setup/#registering-the-first-user

To invite a user, click on the Focalboard logo in the top left, Invite users, Copy link.

There doesn’t appear to be anyway to manage users or non-owned boards, you can reset a user’s password through commands, https://www.focalboard.com/guide/admin/#resetting-passwords

I like that they show the team on the About Us page, always makes me trust companies more. I also like that they have fun with the branding and mascot.

I’ve used Namecheap for several years, no problems experienced with it.

Yeah, that’s kind of what I expected and I am now thinking of keeping my setup how it is currently and getting a mini PC for less important data and services to tinker with.

Thanks for the reassurance. What I currently have is exactly that, RAID for the local data, and a spare drive that is mounted and unmount when data is backed up, and that is rsynced offsite to a cloud provider. I figured that my current setup was really reliable as I had slowly been researching and working on this over a few years.

I have a sort of itch to play with a mini PC, I guess it would be best not to hurt any of my important data by downgrading the setup, however this is a good time to really sort and figure out what I need and is important and what isn’t as important and can be reobtained if something fails on the mini PC.

Thanks for that information about iSCSI, I hadn’t looked into it. I will probably just stick with my primary server for the moment, maybe rebuild it into a NAS, and than use mini PCs with it as the storage.