Known bugs:
- In Turris OS 6.1.0, we introduced VLAN support for WAN interface, but it seems that in some cases, the LAN page is not working. Bug report:
MOX A+D 6.1.0 → 6.2.0
No hiccups, reboot worked fine.
Thank you team!
1 Like
After update Turris 1.x works without problem.
But kernel is always 5.10.161.
1 Like
Yep… it will stay on Linux kernel 5.10.x for some time until the PHY issue with WAN is investigated and narrowed down. Sorry!
The configuration problem with Nextcloud remains. Syncthing now installs, but the service is not automatically activated and after activation I don’t know how to log in. What would be the credentials? I see that the syncthing user is created.
There wasn’t mention of anything related to Nextcloud in the release notes for this release. Was it? I am so sorry to tell you this, but we are not going to address all issues at once in releases. That’s not even possible. And we are not going to increase the priority for the issue, which you have already reported to us if you are going to spam every thread. 
What I can reveal now is that we will release another Turris OS release in such a short time, where we fixed the regression caused in Turris OS 6.1.0 related to the LAN page and nothing else.
If you want to look under the hood, please check the response from my colleague, which he replied to you here:
TL;DR: The issue is not confirmed. The issue it lacks some details which would help us to reproduce it.
Ok, I will take it from the end.
user:
Not every process is running under the root and that’s the case with syncthing. The process has its own user under which is started.
credentials / how to log in to syncthing:
For the syncthing, there are two ways, how you can access the own web interface.
-
The easiest way is to access http://yourrouterip/syncthing/ and it will ask you for your root credentials. Similarly, as it is done for Transmission WebApps. We will later convert this to Turris Auth integration, but that’s will most likely be done in one of our feature releases to split those changes into small releases instead of one huge update.
-
If you want to avoid our WebApps integration, then it is just fine, but you need to change the gui_address in the config to get this working.
What you should do is to configure the syncthing interface once accessed.
the service is not automatically activated:
You want to configure the service first and then enable it. That’s the OpenWrt behavior for this package: packages/syncthing.conf at ce0679b61a5927ffdbc8a1505ce52756c6c394d4 · openwrt/packages · GitHub
1 Like
Turris Omnia, Upgrade from 6.1.0 to 6.2.0 - works as expected.
Minor issue observed:
Default landing page of web user interface was showing no web apps once the Omnia was restarted.
Issue was resolved by reloading the page (Mac, Safari 16.1).
1 Like
I thank you for your response. It was not meant to be a complaint. I am perfectly fine with the development and I always thank your team for their helpfulness over the years. I just wanted to let people know what is still wrong, not because I expected it to be fixed already. But indeed it was unnecessary repetition. I will pay more attention to it 
Syncthing finally installed. But the user experience of a fresh install is really bad.
- Clicking the Syncthing webapp icon leads to a 404 page
- Syncthing needs manual configuration and to be explicitly enabled in config file, but nothing tells this to the user. Could you at least create a reforis notification pointing to some tutorial?
- Once I found and enabled the config, neither the webapps address nor the
http://127.0.0.1:8384address from the config work (when accessing it from browser as http://<ROUTER_IP>:8384). I played a bit with it and finally,option gui_address 'https://<ROUTER_LAN_IP>:8384'works. But still, the webapp link is broken. When I triedoption gui_address 'https://<ROUTER_IP>/syncthing', it did not work. What am I supposed to do to get the syncthing appear onhttps://<ROUTER_IP>/syncthingand work from the webapps? - Once I got in via the IP:port address, Syncthing did not want any password and showed a warning that a password needs to be set. This might be acceptable, as it doesn’t break anything and syncthing shows clear warning and a button to go to settings directly (although to wrong page in settings).
- The default sync folder
/Syncshows an error that it cannot be created. That’s right, because no such path exists on the router and/has no write permissions for the syncthing user. Deleting this folder and setting up a proper one works okay, but wouldn’t it be better to right away create a data folder in/srvand set that one as the default one? - What is the generally suggested way of permissions management? For syncthing to work, I need the syncthing user to have access to the files, but most files are created as the root user. How am I supposed to make sure there aren’t files syncthing cannot access because of permissions in the sync folder(s)?
- I haven’t found anything about syncthing on docs.turris.cz .
1 Like
Turris 1.x, update ok, but Syncthing failing to install with:
Updater execution failed:
inconsistent: Requested package syncthing that is not available."
I will provide the package as virtual for Turris 1.x, so the update can proceed and you don’t get this notification every day.
Thanks, didn’t catched that. However - sad news for 1.x 
Still looking for painless way how to sync/backup part of data on a turris hdd to some cloud…
Can’t you run Syncthing in an LXC container?
If I understand it correctly - for Turris 1.x - no, because of golang dependency, which is not available for ppc platform (generally as I understand). Same thing is rclone.
Turris 1.x, update 5.4.4 ->6.2.0 blocked by package python-pip, after removal of that package ok, except:
all LEDs bright blue, both CLI nad GUI tools for controlling the LEDs failing
rainbow reset
reader_loop: bad jump: 8388608
Aborting...
luci-app-rainbow - 2.2-2
rainbow - 0.1.3-3
rainbow-animator - 0.1.3-3
rainbow-button-sync - 0.1.3-3
turris1x-rainbow-backend - 0.1.3-3
See also Turris OS 6.0.2 is now released - #20 by skorpil_cz
Edit: The solution is:
mv /etc/config/rainbow /etc/config/rainbow_old
After that, it is possible to genetate a new config via GUI.
Then reboot because restarting the rainbow service doesn’t work.
It is then also possible to adjust brigtness but some errors persist:
rainbow brightness 1
Command failed: Not found
Command failed: Not found
Turris 1.0
6.0.4 → 6.2.0
Looks everything is working like in 6.0.4, only WLAN LED is not flashing/lighting. But it was not working also on 6.0.4. All other LEDs works fine and it is possible to change color by Rainbow in LuCI. The LED is not damaged, during boot or after rollback to TOS 3.11 it works
That affects only Turris 1.x routers running LTS kernel 5.15 and yes, there is such issue, where we are tracking it, but it is not public right now.
1 Like