But AI will fix it for us …

How bloody annoying! Trying to move the tree to another VM and exported *.gramps file from other VM where it was working but get the same problem around the database being locked. It means that the GRAMPSWEB_TREE: setting in the compose file makes no difference. Makes no difference whether I try importing as admin. This is also a single tree setup. This issue is really annoying. Wish the docs referenced it.

Can I just check with @tiptoes@sh.itjust.works and @Eggymatrix@sh.itjust.works that what I’m doing is what you are saying.

I’m not setting static IPs at client level. Would be a nightmare. What I do is assign IPs on the DHCP server i.e MAC address on VM1 is XX:XX:XX:XX so I set this MAC address in DHCP to correspond to IP 192.168.20:XX so that the machine gets a unique IP all the time. Is this what you meant? I thought everyone would be doing this nowadays as it so easy to manage, except when something goes wrong like in this case.

Maybe I’m misunderstanding but what I mean is that I assign static IP via DHCP based on the MAC. I’m not setting static IPs at client level. i.e MAC address on VM1 is XX:XX:XX:XX so I set this MAC address in DHCP to correspond to IP 192.168.20:XX so that the machine gets a unique IP all the time. Is this what you meant?

See message above. I doubt it. I would have had this problem a lot earlier with other machines.

Well, because its all managed in one place rather than having to go and configure loads of machines

Yeah, but these little Optiplex machines only take one NVMe at a time I think. In your article it sounds like you have a tiny NVMe drive for Proxmox and an SSD (on the SATA port presumably) for the storage. Is this right? I think the Optiplex 5070 allows both NVMe and SSD at the same time, but not 100% sure.

I’m picking up on this because I’m getting a bit confused. I’ve run this through docker compose using the below yaml. I’ve done it as normal user, “Fred” (added to docker group) rather than root (using sudo although it make no difference as I get the same outcome). I normally have a “docker” folder in my /home/fred/ folder so is /home/fred/docker/vaultwarden in this instance (i.e. my data folder is in here).

I get the same issue highlighted here which is all about the SSL_ERROR_RX_RECORD_TOO_LONG when trying to connect via https, whereas when I try to connect via http, I get a white page with Vaultwarden logo in top left corner and the spinning wheel in the center. I’ve got no proxy enabled and I’m still not clear why I need one if I’m only accessing this via LAN. Is this something on the lines of “you must yse this through a proxy or it won’t work” thing? Although that not why I understood the from the guidance. I’m clearly missing something although not sure what exactly it is …

services:
  vaultwarden:
    image: vaultwarden/server:latest
    container_name: vaultwarden
    restart: always
    environment:
      # DOMAIN: "https://vw.home.home/"
      SIGNUPS_ALLOWED: "true"
    volumes:
      - ./vw-data/:/data/
    ports:
      - 11001:80

And, i can’t find clients on f-droid. Any variants recomended that dont come from the playstore.

Another key feature will be Keepass data import.

That is another problem i face when i have the app open on desktop and phone at the same time. Its a nightmare.

This is a good comment! I just discovered after your comment that floccus has a setting to link up with Linkwarden so that together, they achieve most of my desired outcomes. It just becomes more i volved in the managemente as you no end up with two components to manage rather than one ;-)

Mate, it was a sarcastic statement 😉

Well no. Initially i had the storage set on the VM where its running. I wasn’t expecting it to download all that data.

I was using floccus, but what is the point of saving bookmarks twice, once in linkwarden and once in browser

absolutely, none of that is going past my router.

Interestingly, I did something similar with Linkwarden where I installed the datasets in /home/user/linkwarden/data. The dam thing caused my VM to run out of space because it started downloading pages for the 4000 bookmarks I had. It went into crisis mode so I stopped it. I then created a dataset on my Truenas Scale machine and NFS exported to the VM on the same server. I simply cp -R to the new NFS mountpoint, edited the yml file with the new paths and voila! It seems to be working. I know that some docker container don’t like working off NFS share so we’ll see. I wonder ho well this will work when the VM is on a different machine as the there is a network cable, a switch, etc. in between. If for any reason the nas goes down, the docker containers on the Proxmox VM will be crying as they’ll lose the link to their volumes? Can anything be done about this? I guess it can never be as risilient as having VM and has on the same machine.

The first rule of containers is that you do not store any data in containers.

Do you mean they should be bind mounts? From here, a bind mount should look like this:

version: ‘3.8’

services: my_container: image: my_image:latest volumes: - /path/on/host:/path/in/container

So referring to my Firefly compose above, then I shoudl simply be able to copy over the /var/www/html/storage/upload for the main app data and the database stored in here /var/lib/mysql can just be copied over? but then why does my local folder not have any strorage/upload folders?

user@vm101:/var/www/html$ ls index.html

Here is my docker compose file below. I think I used the standard file that the developer ships, simply because I was keen to get firefly going without fully understanding the complexity of docker storage in volumes.

 The Firefly III Data Importer will ask you for the Firefly III URL and a "Client ID".
# You can generate the Client ID at http://localhost/profile (after registering)
# The Firefly III URL is: http://app:8080/
#
# Other URL's will give 500 | Server Error
#

services:
  app:
    image: fireflyiii/core:latest
    hostname: app
    container_name: firefly_iii_core
    networks:
      - firefly_iii
    restart: always
    volumes:
      - firefly_iii_upload:/var/www/html/storage/upload
    env_file: .env
    ports:
      - '84:8080'
    depends_on:
      - db
  db:
    image: mariadb:lts
    hostname: db
    container_name: firefly_iii_db
    networks:
      - firefly_iii
    restart: always
    env_file: .db.env
    volumes:
      - firefly_iii_db:/var/lib/mysql

  importer:
    image: fireflyiii/data-importer:latest
    hostname: importer
    restart: always
    container_name: firefly_iii_importer
    networks:
      - firefly_iii
    ports:
      - '81:8080'
    depends_on:
      - app
    env_file: .importer.env

  cron:
    #
    # To make this work, set STATIC_CRON_TOKEN in your .env file or as an environment variable and replace REPLACEME below
    # The STATIC_CRON_TOKEN must be *exactly* 32 characters long
    #
    image: alpine
    container_name: firefly_iii_cron
    restart: always
    command: sh -c "echo \"0 3 * * * wget -qO- http://app:8080/api/v1/cron/XTrhfJh9crQGfGst0OxoU7BCRD9VepYb;echo/" | crontab - && crond -f -L /dev/stdout"
    networks:
      - firefly_iii
volumes:
   firefly_iii_upload:
   firefly_iii_db:

networks:
  firefly_iii:
    driver: bridge

They are mostly cash. On average 5-10/day over a 5 hrs day.

Ah right. Docker seems to have gained more ground than LXC if its the first time I come across it. I hadn’t realised they were similar, especially after I discovered that people are running docker in LXC …