link icon
Ask The Community

Security/ Bad Packaging: Teamviewer updates re-enable disabled teamviewerd.service

I have disabled teamviewerd.service for security reasons with "sudo systemctl disable teamviwerd.service". I only start the service when I actually need to use Teamviewer.

I notice that every Teamviewer update overwrites the systemd configuration and re-enables the background service without my consent. I am not happy with the behaviour of Teamviewer updates und would highly recommend to modify the installation script in a way that the user is asked if the startup configuration should be changed or not. This is common practice in the Linux world.

My system: Ubuntu 18.04 64bit.



  • I've been running into this problem for a while, too, and was hoping that the company Teamviewer would eventually fix this on their own.  That didn't happen.

    This is incredibly annoying as I have to manually disable and stop teamviewer on every update. If your daemon is disabled, it should *stay* disabled.

    Please remove that "feature", thanks.

  • I agree with this, especially since it is pulling logs from other services on the system. For now I am running the following cronjob.

    @reboot /usr/bin/bash -c '[ `systemctl is-enabled teamviewerd` != 'disabled' ] && systemctl disable --now teamviewerd'
  • ivosm
    ivosm Posts: 1

    There are sure solutions like cron script but I am convinced, that sw is very much about trust and the question is, how can I trust sw incl. its producer, who enable access to my computer despite I refused it.

    1. Such an importatnt item should be manageble and visible even by very stupid user because of even he/she has the right to make the decision when exactly to open and when to close this door. So even workable commandline solution is bad.

    2. I had a problem with teamviewer even before, because of I didn't see a clear description, who has the control of the permission list? Is that done e.g. by some keystore on my computer (where:?) or is that somewhere at Teamviewer server? I.e. is that technically possible, that Teamviewer company "changes my decision" simillarly to the one of not starting the service?

    The second item was a blocker for me for professional use, the mentioned re-enabling of running in background means sorry for my mum, who likes it.

    From my point of view is the only solution uninstall and check some possible residuals.


  • This is something that also annoys me for a long time.
    Recently I tweeted to @teamviewer_help and they were, at least, responsive.

    As I said in one of my tweets I would be glad to help fixing this.
    I had a look at the RPM postinstall script to understand what changes would be required.The following changes should do it for systemD but a little bit more effort is required to support other tecnologies.

    *** 2020-05-28 10:59:00.**Please do not post TeamViewer IDs** +0100
    --- 2020-05-28 10:58:36.**Please do not post TeamViewer IDs** +0100
    *** 25,35 ****
    local installCount="$1"
    local action=$(RPMAction)

    ! [ "$action" = 'upgrade' ] && removeDaemon # during upgrade: remove daemon, then reinstall


    function Configure()
    --- 25,48 ----
    local installCount="$1"
    local action=$(RPMAction)
    + local daemonStatusBeforeUpgrade

    ! if [ "$action" = 'upgrade' ]; then
    ! # save daemon status so that it can be restored after the upgrade
    ! daemonStatusBeforeUpgrade=$( cmdDaemon 'status' )
    ! removeDaemon # during upgrade: remove daemon, then reinstall
    ! fi

    + # restore service status before the upgrade
    + case "$daemonStatusBeforeUpgrade" in
    + disabled)
    + cmdDaemon 'disable'
    + ;;
    + esac

    function Configure()

    If there's a plan to implement such a fix, I am available to provide additional help.

    Paulo A. Silva

Sign In or Register to comment.