Beiträge von Morlan

Then you should use your own domain instead of duckdns

Zitat von FredK

After updating nextcloud to 20.0.5 I get the following warning in Settings->Overview

Anybody aware of a MariaDB docker version 10.2ff for the system specified in my signature?

This is a complicated issue. Because MariaDB is not officially compiled for arm32 devices the linuxserver image is stuck on 10.1.*. I don't know if that will change. I tried to find an alternative this morning, but I have not found an easy solution .. Maybe someone else has an idea?

Are the container still in a docker network together?

And do you still have the subdomain in the docker-compose.yml?

it sort of worked for (interface was looking strange) with this config:

server {

listen 443 ssl;

listen [::]:443 ssl;


server_name motioneye.*;


include /config/nginx/ssl.conf;


client_max_body_size 0;

location /cams/ {

        include /config/nginx/proxy.conf;
        resolver 127.0.0.11 valid=30s;
        set $upstream_app motioneye; 
        set $upstream_port 8765; 

        set $upstream_proto http;

        proxy_pass $upstream_proto://$upstream_app:$upstream_port/;

        access_log off;

}
}

Running a secound swag container is complicated. Its not advised...

Is it possible to set up motioneye without cameras ? If yes I could try to set it up...

server {

listen 443 ssl;

listen [::]:443 ssl;


server_name motioneye.*;


include /config/nginx/ssl.conf;


client_max_body_size 0;

location /cams/ {
        
        include /config/nginx/proxy.conf;

        resolver 127.0.0.11 valid=30s;

        set $upstream_app motioneye; # use ip instead of name if name is not working

        set $upstream_port 8765; # note: as trilium is sharing the same docker network as letsencrypt, internal port to be used

        set $upstream_proto http;

        proxy_pass $upstream_proto://$upstream_app:$upstream_port;
        proxy_read_timeout 120s;
        access_log off;

}
}

restart your swag container

and try to reach motioneye with https://motioneye.yourdomain.duckdns.org/cams/

can your post your motioneye.subdomain.conf?!

https://github.com/ccrisan/mot…wiki/Running-Behind-Nginx

as a hint what you put into the motioneye.subdomain.conf

Zitat von STUKguy

- SUBDOMAINS=www,

in the swag part of the docker-compose.yml add motioneye as a subdomain:

Zitat von STUKguy

- SUBDOMAINS=www,motioneye

do you have a lot of stored images ? docker image ls --all

I'd suggest you ask at the dockSTARTer community. This does not seems specific to OMV.

https://dockstarter.com/#support

Zitat von prashkd

I read somewhere that OMV 6 will only be supporting btrfs

As far as I read there is a discussion about using BTRFS as the underlaying filesystem for the OMV install. I'm certain OMV will still support all regular linux filesystems for your datadisks. So from that perspective there is no pressure to use BTRFS.

Zitat von prashkd

i was wondering if its safe to use command line to setup filesystem

Set up the filesystem with the OMV Gut and then configure the snapshots / backups via the command line. But I strongly suggest to familiarize yourself with the filesystem first before completely relying on it. That involves reading the documentation and researching the tools (e.g. btrbk or snapper for automated snapshots), so in case of a problem you know what to do.

As stated in the article I linked. Conventional tools, which are not aware of the CoW-Filesystem which is BTRFS will see every snapshot as an individual set of files and will calculate the size as such. Might be that the actual size consumption of the sub volumes is much smaller because duplicate files are just referenced twice...

How did you check the space consumption? Docker uses BTRFS subvolumes/snapshots a lot when building container layers.

Maybe this article might help you: https://btrfs.wiki.kernel.org/…almost_nothing_into_it.21

try this docker-compose.yml ( with custom network and containers names). I hope the indentation works with this code. You might have to adjust it...

version: "3.4"
services:
  broker:
    container_name: paperless_broker
    image: redis:6.0
    restart: always
    networks:
       - my-net

  db:
    container_name: paperless_db
    image: postgres:13
    restart: always
    volumes:
      - pgdata:/var/lib/postgresql/data
    environment:
      POSTGRES_DB: paperless
      POSTGRES_USER: paperless
      POSTGRES_PASSWORD: paperless
    networks:
       - my-net

  webserver:
    container_name: paperless_web
    image: jonaswinkler/paperless-ng:0.9.11
    restart: always
    depends_on:
      - db
      - broker
    ports:
      - 8888:8000
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000"]
      interval: 30s
      timeout: 10s
      retries: 5
    volumes:
      - data:/usr/src/paperless/data
      - media:/usr/src/paperless/media
      - export:/usr/src/paperless/export
      - consume:/usr/src/paperless/consume
    env_file: docker-compose.env
    environment:
      PAPERLESS_REDIS: redis://paperless_broker:6379
      PAPERLESS_DBHOST: paperless_db
    networks:
       - my-net


volumes:
  data:
  media:
  pgdata:
networks:
  my-net:
     name: my-net

Zitat von Agricola

Portainer and docker-compose are only compatible table with version 2.

That's not entirely true. Only the stacks function of Portainer is incompatible with docker-compose version > 2. Docker-compose itself supports Version 3.x.

Now the docker-compose.yml contains your email address and your duckdns token (you should the token).

SUBDOMAINS needs to be wildcard or empty when using duckdns authentication.

Check the official readme: https://github.com/linuxserver/docker-swag

your compose file states SUBDOMAINS=wildcard

but the log file says SUBDOMAINS=www,

That doesn't really add up

Also heads up: The log file still contains an email address

When setting up the docker, did you use the network: host option?

When I tested the image this was necessary for broadcasting to work. But this was some time/versions ago.

The most valuable lessons you need to learn from this situation is that you need a backup of your data. This way there wouldn’t have been a cause for panic.