acook

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by acook

  1. Hi there, Thanks for the great plugin, and for adding the option to ignore errors during backup. I was wondering how hard it would be to change the logic for stopping docker containers during backup. Instead of stopping all containers upfront, doing the whole backup, and then starting all containers it would be cool if each container was only stopped during its own backup. Basically loop through each docker app that isn't marked "don't stop", stop the container, back up its app data, start the container, move on to the next app.
  2. Just wanted to provide an update. I haven't gotten to the bottom of why the network (and routing tables) suddenly disappear, but when it happens I'm able to fix it with the following commands (I reverse engineered the /etc/rc.d/rc.docker script) ip link add shim-br0 link br0 type macvlan mode bridge ip link set shim-br0 up ip route add 192.168.1.0/25 dev shim-br0 ip route add 192.168.1.128/25 dev shim-br0 Hopefully this helps someone else fix the issue in the future. Edit: And for those using ipvlan ip link add shim-br0 link br0 type ipvlan mode l3 ip link set shim-br0 up ip route add 192.168.1.0/25 dev shim-br0 ip route add 192.168.1.128/25 dev shim-br0
  3. I run into this same problem time and time again. Every so often my server suffers from a kernel panic. Once it reboots, the routing tables and docker networks are missing. Even if I disable/enable Docker the routing tables don't get added back. Usually a reboot fixes it, but not always. This is what the routing tables should be when correct # ip route show default via 192.168.1.1 dev br0 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 192.168.0.0/16 via 192.168.0.2 dev tun0 192.168.0.2 dev tun0 proto kernel scope link src 192.168.0.1 192.168.1.0/25 dev shim-br0 scope link 192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.100 192.168.1.128/25 dev shim-br0 scope link 192.168.3.0/25 dev shim-br0.3 scope link 192.168.3.128/25 dev shim-br0.3 scope link 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown And this is what it looks like when things are broken default via 192.168.1.1 dev br0 172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 192.168.0.0/16 via 192.168.0.2 dev tun0 192.168.0.2 dev tun0 proto kernel scope link src 192.168.0.1 192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.100 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown Adding the route manually throws an error, as the device doesn't exist. For example # ip route add 192.168.3.0/25 dev shim-br0.3 Cannot find device "shim-br0.3" Any ideas how I can prevent this from happening? Or how I can correctly add these routing tables myself?
  4. Hello, I'm having a problem mounting my grdive. I'm pretty sure it was working a few weeks ago. I tried removing and installing from the latest template, but I'm getting this error Executing => rclone mount --config=/config/.rclone.conf --allow-other --read-only gcrypt-direct: /data 2019/02/22 22:12:08 mount helper error: fusermount: user has no write access to mountpoint /data 2019/02/22 22:12:08 Fatal error: failed to mount FUSE fs: fusermount: exit status 1 I'm running on the latest dev version and am using this startup command --cap-add SYS_ADMIN --device /dev/fuse --security-opt apparmor:unconfine -v /mnt/disks/rclone_volume/:/data:shared I tried using rw instead of shared, but it didn't help. Any ideas? Thanks!