Just to finish this off: the failure in assigning a seat to the session is caused by systemd-logind. Explanation here: https://wiki.archlinux.org/index.php/NIS#Attention_on_Systemd_V235_since_10/2017_(and_V239_since_06/2018,_and_V245_since_03/2020) Solution here: https://superuser.com/questions/1563951/systemd-does-not-assign-a-seat-to-my-session-when-using-nis-authentication Once this problem is solved TeamViewer is running again.
... View more
I did that but it did not help. I did discover the cause though, but not the solution. When I log in locally, my session gets a seat assigned. I can see that with loginctl: jlinkels@donald-pc:~$ loginctl
SESSION UID USER SEAT TTY
3 1000 jlinkels seat0 However, when I log in using NIS (what I do on my network) logind does nog assign my session a seat: jlinkels@donald-pc:~$ loginctl
No sessions. This has implications for the use of the scanner, sound, webcam etc. Apparently as well on TeamViewer. Which is understandable as TeamViewer wants to share the screen. When I installed TeamViewer, I was still in local login mode, working on troubleshooting. Then I must have switched back to NIS, rebooted, and some days later I found that TeamViewer was not working. To make sure this is the problem, I switched back to local login and tested. TeamViewer is fine. So this is not a TeamViewer problem but a system problem. Which I do want to solve. For the scanner and other pluggable hardware I was able to modify udev rules and give group permissons to devices. Like it was done before Debian 10. Not sure if I can create such a workaround for TeamViewer as well. As I have no idea where and why TeamViewer checks for seats.
... View more