Check this out - I had similar issues with a OnePlus phone, issues solved after applying that fix.
What’s new in 7.6beta6 (2022-Sep-07 12:06):
*) container - added “start-on-boot” parameter for automatic container startup;
*) dot1x - fixed incorrect error when using “mac-auth”;
*) l3hw - fixed possible packet loss when using HW offloaded NAT;
*) lte - fixed at-chat on Telit FN980m;
*) ntp - improved initial synchronization speed after bootup;
*) ospf - added SHA hashing for authentication;
*) ospf - refresh OSPFv3 interface configuration when IPv6 network becomes available;
*) ovpn - added IPv6 support for ethernet mode;
*) ppp - fixed memory leak;
*) ssh - increased key generation timeout;
*) system - renamed error messages when trying to edit or remove dynamic entries;
*) user-manager - allow specifying router’s address as subnet;
*) user-manager - fixed “migrate-legacy-db” command;
*) user-manager - fixed session expiry when it is stopped by Disconnect-Request;
*) w60g - improved system stability (introduced in v7.5);
*) wifiwave2 - fixed “WPA Key Data Length” value in EAPOL frame when FT-EAP-SHA384 AKM is used;
*) winbox - added “Rapid Commit” parameter support under “IPv6/DHCP-Server” menu;
*) winbox - allow to rename mounted disks;
*) winbox - fixed “Session Uptime” value for not established sessions under “Routing/BGP” menu;
*) winbox - fixed “System/SwOS” window refreshing after changes are detected;
*) winbox - fixed “User Manager/User Profiles” window refreshing after changes are detected;
*) winbox - made sessions removable in “User Manager” menu;
*) winbox - show “Switch” menu on Chateau LTE18 ax;
*) winbox - show “System/RouterBOARD/Mode Button” on devices that have such feature;
*) wireguard - strip whitespaces from keys;
If i used mount point like /diskN/adguardhome/work or /diskN/adguardhome/data, I got permission denied as the fatal error and AdGuard Home just can not be brought up.
I learnt that this issue can be fixed by inserting the USB disk to a Linux machine and create folders with 777 permission manually.
Do you have any advice, pls? Is this a bug that mikrotik should solve? Thx.
MT Staff, please fix this bug, on this post is also present the ready soluction…
http://forum.mikrotik.com/t/v7-5-stable-is-released/160518/1
how to enable this option - container - added “start-on-boot”
command line?
Read guide?
model RB5009UG+S+
ros 7.6beta4 create container AdGuard Home, upgrade to 7.6 beta6, don`t run
log
17:00:55 container,info,debug 2022/09/07 14:00:55.135264 [info] AdGuard Home, version v0.107.11
17:00:55 container,info,debug 2022/09/07 14:00:55.265404 [info] Initializing auth module: /opt/adguardhome/work/data/sessions.db
17:00:55 container,info,debug 2022/09/07 14:00:55.265558 [error] auth: open DB: /opt/adguardhome/work/data/sessions.db: open /opt/adguardhome/work/data/sessions.db: permission denied
17:00:55 container,info,debug 2022/09/07 14:00:55.265614 [fatal] Couldn’t initialize Auth module
/container mounts
add dst=/opt/adguardhome/work/data name=adguardhome_data src=/container/adguardhome
add dst=/opt/adguardhome/conf/ name=adguardhome_conf src=/container/adguardhome
add dst=/opt/adguardhome/work/ name=adguardhome_work src=/container/adguardhome
/container
add interface=veth1 logging=yes mounts=adguardhome_data,adguardhome_conf,adguardhome_work root-dir=container/adguardhome workdir=/opt/adguardhome/work
/container config
set registry-url=https://registry-1.docker.io tmpdir=container/tmp
please fix it
Why are you creating duplicated, nested mounts for /opt/adguardhome/work and for /opt/adguardhome/work/data? This might be your problem.
Create just one mount for /opt/adguardhome/conf and another one for /opt/adguardhome/work and it should work. It is working here for me using this configuration:
/interface veth
add address=172.31.0.1/24 gateway=172.31.0.254 name=adguard
/container config
set ram-high=768.0MiB registry-url=https://registry-1.docker.io tmpdir=disk1/container-tmp
/container mounts
add dst=/opt/adguardhome/conf name=adguard-opt-adguardhome-conf src=/disk1/adguard-opt-adguardhome-conf
add dst=/opt/adguardhome/work name=adguard-opt-adguardhome-work src=/disk1/adguard-opt-adguardhome-work
/container
add dns=172.31.0.254 hostname=adguard interface=adguard mounts=adguard-opt-adguardhome-conf,adguard-opt-adguardhome-work root-dir=disk1/adguard remote-image=adguard/adguardhome:latest
this post v7.6beta [testing] is released! - #47 by tpedko
previously done as you suggested, result does not change.
I guess this was a workaround for when it was not possible to create folders/directories inside container mounts. It was a restriction on RouterOS containers that was fixed in 7.5rc2, I think.
To my understanding you should never create nested mounts like you did.
And, as I said before, it is working great on my RB5009UG+S+ using the configuration I shown.
Installed on RB3011. This function does not work consistent.
I’ve 2 containers (Pihole & Adguard) and only Adguard “auto-boots”
Both have the correct flags. Pihole can be started manually, it starts without a problem.
Did not re-create container from scratch since enabling the option worked fine for Adguard.
Anyone else this experience with 2 containers + auto-start ?
in this release, in BGP sessions
- missing RemoteID, Remote Capabilities, Prefix count & Uptime…
- Not refreshing sessions list, I have to change tab and come back to view new sessions up…
There was a bug that prevented mounts from working properly, that bug was silently fixed in 7.6beta4.
Every “solution” posted up until v7.6beta4 were ugly hacks.
Containers should have root-dir set to a directory dedicated for containers, in a unique directory for each container.
Same goes for mounts.
I use something like this:
/container mounts
add dst=/opt/adguardhome/conf name=agh_conf src=\
/disk1/docker/mounts/agh/conf
add dst=/opt/adguardhome/work name=agh_work src=\
/disk1/docker/mounts/agh/work
/container
add interface=veth2 logging=yes mounts=\
agh_conf,agh_work root-dir=\
disk1/containers/adguardhome workdir=\
/opt/adguardhome/work
/container config
set ram-high=96.0MiB registry-url=\
https://registry-1.docker.io/ tmpdir=\
disk1/docker/tmp
*) winbox - fixed “Session Uptime” value for not established sessions under “Routing/BGP” menu;
this for me is untrue, because uptime is empty any way, for estabilished and not estabilished sessions.
the difference from previous version is the before it was a coundown, now it is just empty.
regards
Ros
Being empty is their fix for now. They had completely removed the uptime field for some reason, I believe on purpose. You cannot see it in the CLI at all either (and you could in earlier versions when it displayed properly in Winbox), but when they removed it from the CLI, Winbox started displaying some strange value as a glitch instead of displaying nothing, like the command line does.
I assume it will be put back in the CLI and winbox at some point, but it is not a bug, it is just a feature that seems to have been temporarily removed.
The previous version showed the current uptime in commandline but when you opened the sessions tab in winbox it showed a fake ticking uptime…
Even when the session is down or has been down/up, still it showed the incorrect ticking time until using F5 to refresh it.
In v6 the screen is automatically refreshed to show the real values (not only uptime but also remote ID, prefix count, state etc).
I hope in v7 a screen like that will come back, instead of more and more info being removed.
I’m still running 7.5 with BGP and can confirm that it does not show the uptime in the command line, and it displays in winbox with a fake uptime.
I have another router running BGP on 7.4 and that does show the uptime in the command line, but it also shows the correct uptime in winbox.
Which version is it that you speak of that shows the correct uptime in the CLI but the wrong uptime in Winbox?
What I mean with previous version is the 7.4 behavior. The winbox uptime is copied from the router when you open the window, but then it continues ticking upward even when the connection actually is down.
Got it from the help wiki.
Can add to the existing running docker
I understand now. I suspect, to fix this issue, they might have had to re-engineer the peer uptime display a bit, and that would explain why it has been temporarily removed.