Beiträge von nick2k3

HI, i actually need an updated kernel to solve the macvlan issues already highlighted in other threads and have been forced to run the rpi-update to have a kernel version that solves it.

That has been annoying me a bit bc I know i should not be running untested kernel on a regular basis.. every updates makes me shiver

I have a "test" RPi to try some functionality out and report if I found any issues.

Hi everyone! I just noticed that RPI kernel was bumped to 5.4.42. has anyone been using that kernel with OMV and a Raspberry Pi?

Is there any concerning thing I should keep in mind before upgrading ?

(other tha an SD backup of course)

Thanks!

Hi, just pulled netdata/netdata:latest and the problem is fixed.

Just to double check, the current latest is v1.22.1-16-g18ec989b

Zitat von Wek

Hi nick2k3 my phone wireguard config also seems fine:

Code

[Interface]
Address = 10.13.13.2
PrivateKey = xxxxxxxxxxxxx
ListenPort = 51820
DNS = 10.13.13.1

[Peer]
PublicKey = xxxxxxxxxxxx
Endpoint = mambojambo.duckdns.org:51820
AllowedIPs = 0.0.0.0/0, ::/0

and ipv4 forward is also enabled:

Code

root@omv:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

I don't know what else to think about.

The only thing that I see strange is DNS = 10.13.13.1 on the config, because my normal intranet get dns by my isp through 192.168.1.1 but then again I guess wireguard creates another subnet so I guess is fine, so I'm out of ideas here.

tinh_x7 thank you, I was more asking specifically about wireguard if it would be better to run directly on the machine instead of docker, because of all this issue the container is giving me, but whatever works it's ok, it's just strange that the lan works but not the wan, but as you can see the config seems fine.

Alles anzeigen

Hi, I had similar problems. try to change the DNS on your client configuration to 1.1.1.1 or something similar, outside of your network.

I am afraid that dns requests are not forwarded by the docker gateway to the host's default DNS.

In my network I use Pihole on another system than the host on which wireguard runs and I have set the DNS on the client to that host. It works!

But if I leave the self generated DNS ( 10.13.13.1in your case) i had problems.

Zitat von Wek

Hi I have the same issue of tinh_x7, wireguard is working fine to access the smb share of omv through my phone when connected to wireguard vpn, but I cannot access internet, use of firefox or other apps it says there is no internet connection.

The config file of the server seems fine:

Code

[Interface]
Address = 10.13.13.1
ListenPort = 51820
PrivateKey = xxxxxxxxxxxxx
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = xxxxxxxxxxxxxxx
AllowedIPs = 10.13.13.2/32

[Peer]
PublicKey = xxxxxxxxxxxxx
AllowedIPs = 10.13.13.3/32

[Peer]
PublicKey = xxxxxxxxxxxxxx
AllowedIPs = 10.13.13.4/32

Alles anzeigen

My router is forwarded correctly (otherwise my phone would not work even to browse lan, as I tested it without using the wifi, but only cellular data).

I'm using the docker container from linuxserver.

Is it better at this point to discard, the container\docker way, go directly the debian way installing wireguard from the buster-backports and configure it manually instead?

Alles anzeigen

can you check if the host machine is configured to forward ipv4 packets?

run this command

pi@raspberrypi:~ $ sysctl net.ipv4.ip_forward 
it should result in:
net.ipv4.ip_forward = 1

if it's 0 your machine receives packet from the phone which are intended to the outer internet but instead drops them

also check, on your phone wireguard configuration that the AllowedIP is 0.0.0.0

Updated to the latest version and it's solved!!

Thanks again for the super fast fix!

Zitat von tinh_x7

Port 51820 has been port forwarded in the router.

I'm going to also check ListenPort = xxxxx later.

are you running using wireguard plugin or through docker from linuxserver?

Zitat von tinh_x7

Hello,

The Wireguard can only connect via intranet, can't access external sites.

Anybody know why ?

are you sure you have opened the port on your router?

In the .conf of the server you should have it set under the parameter:

ListenPort = xxxxx 

if this is not open and redirected from the outside to your wireguard server, then you won't be able to reach it from outside.

I have deleted the tasks.sls then tried to delete one folder again and got the same errors as before.

Re-reading your post I now realize that deleting tasks.sls was not a workaround but rather a preparation for the fix.

If so, I'll wait for the fix, otherwise I am available in case you need to test something more.

Thanks again for the super fast support!

Content of

/srv/pillar/omv/tasks.sls for RPi3:

tasks:
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: bkp_config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: bkp_config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: bkp_config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: bkp_config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: docker_config
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: bkp_config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: config_pihole
- sls: omv.task.sharedfolder_alias.disable
  pillar:
    name: docker_config
- sls: omv.task.sharedfolder_alias.disable
  pillar:

Output of salt-call --local state.orchestrate omv.task on RPi3:

https://pastebin.com/5t5G0vfz

If needed I can run it on the other system too.

Not that I know of. I assume it is something different from the hostname of each rpi, right?

Edit: no,shared folders are disabled by default on RPi4 as it is a new install using the updated script that disables it by default.

On the RPi3 it was enabled but then i disabled it.

Hello everyone,

I have two up-to-date instalations of OMV5 (5.4.5-1) on a RPi3 and RPi4 running in my home.

I noticed I can no longer delete a shared folder: I get an error when applying changes.

Here is a list of what I have tried:

- creating a new shared folder and applying changes : OK

- deleting multiple shared folder at once: same error

- reverting the change: OK

- making another modification and applying changes (i.e. change time zone): OK

- the shared folders are not used in any other point of OMV

- I am not logged in via ssh and "in" one of these folders

- rebooting system : same result

The system on the RPi3 has been installed in mid February.

The system on the RPi4 has been installed around mid april (when OMV5 was considered stable) and kept constantly up-to date.

Around the installation of RPi4 I remembered being able to delete some shares etc.. unfortunately I don't know since when this is broken.

Here below the two error dumps, does anyone know what I could do to investigate further?

Error on RPi4:

https://pastebin.com/iTSKxwV6

Error on RPi3:

https://pastebin.com/qUTW3CRG

Edit: using pastbin as error were too longs for code tags

Zitat von ryecoaaron

Can you use another QR reader to tell me what config it is actually generating? The QR code was the one thing that seemed to working fine.

I think I have narrowed it down. I was using a prefix to the Endpoint (https:// ) I tried removing it, saving and regenerating the QR code but it is not updating.
Even if I replace the endpoint with some bogus IP like 10.0.0.1 it won't regenerate the QR.
I hade to enable and disable the plugin and clear the cache to let it regenerate.
I'll make some more tries.

Zitat von ryecoaaron

There is no PSK setting currently. What does the config line look like?

sorry, my fault, now it is not there, I might have messed up with other tools.

Zitat von ryecoaaron

OMV doesn't work that way. It totally controls the config files. If there is something missing, it should be added to the plugin and/or an extra options field added.

Fair enough, I'll play a bit with it and see if I can put together some modifications for a pull request.

Ok, I'll give it a run once home!

Zitat von ryecoaaron

I haven't touched it. I was waiting for more feedback on what it is doing wrong. As much as I would like to try it out, I haven't had time. So, I haven't really used wireguard and that makes it tough to improve the plugin.

Hi, I have tried it in these days and I have a couple of points:
- the latest version I have tried (last week) generates a QR code which is not readable by the latest version of the iOS wireguard app. It says it is not a valid wireguard configuration.
- I would put a setting to enabling or not the usage of a PSK
- it could be cool if it could just load an existing configuration and start from there, also because it allows a more fine-grained control

If there is anything you want me to test I can try!
Thanks for doing it!

Hi everyone!
I have successfully configured wireguard on my OMV5 raspbian-lite base installation.

I now would like to set it so that it will automatically run whenever I start the system.
I have checked debian wiki and they indicate several strategies:
https://wiki.debian.org/Wireguard

I am considering using "Alternative 2 - systemd" but of course I don't want to "mess" with OMV own control of the interfaces.

Then I am asking, what is the most "polite" way to set something like this in OMV?

PS: I have tried the WG unreleased plugin but it is too limited for now, I would like to configure it manually for the time being

Thanks!

Hi Thanks,
I have done almost everything you said and have my compose file like this:

version: '2'


services:
  traefik:
    container_name: traefik
    image: traefik
    hostname: traefik
    domainname: fritz.box
    command: 
      - --api.insecure=true 
      - --providers.docker 
      - --providers.docker.exposedbydefault=false
      - --entrypoints.web.address=:80
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 8080:8080
      - 80:80
    restart: unless-stopped

version: '2'
services:
  netdata:
    image: netdata/netdata
    container_name: netdata
    environment:
      - PUID=1001
      - PGID=100
    ports:
      - 19999:19999
    expose:
      - 19999
    cap_add:
      - SYS_PTRACE
    security_opt:
      - apparmor:unconfined
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - /etc/localtime:/etc/localtime
      - /srv/dev-disk-by-label-WD1/config/netdata/config:/etc/netdata
    labels:
      - "traefik.http.routers.netdata.rule=Host(`netdata.mars.fritz.box`)"
      - "traefik.http.services.netdata.loadbalancer.server.port=19999"
      - "traefik.enable=true"

but I still cannot manage to connect to netdata.mars.fritz.box

I am quite struggling at this point..

Hi subzero79, I am trying to do exactly what the OP is trying to do but with docker and traefik.

Basically I have all my containers exposing different ports within the local network with domain fritz.box, i.e.:

server_name.fritz.box:1234 //music service
server_name.fritz.box:4321 //photo service
etc..

what I am trying to achieve is reaching the servers like this:
music.server_name.fritz.box
photo.server_name.fritz.box

right now I am struggling a lot. Before asking for further help, can you tell me if this is even possible with traefik?
thanks!

HI, try pushing the "Pull Image" button on the top left corner and type in the image name, see what kind of error you are getting.
If you dont' know the image name you can check them on https://hub.docker.com/search?q=&type=image

I'm so glad you guys are there!!

I have spent the last 24 hours digging on my own setup trying to understand why pihole was not responding after 4-5 minutes.

I have noticed the exact same behavior with 4.19.97-v7+ on Buster and a Pi3 .. I thought the weirdest thing and that I was starting to see things..

One question: as it seems that running rpi-update fixes this, what are the implication on OMV?
is it safe to upgrade the kernel? what difference does it make compared to waiting for the new kernel to pop up in the updates section of OMV/apt-get?

Thanks,