This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(182.40000000000003, 45%, 27%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EMS%3C/text%3E%3C/svg%3E)
The most recent version of the "teams" snap for Ubuntu 20.04 (version 1.4.00.26453) causes constant apparmor messages about attempts to access paths under /sys/ are being DENIED for read access. It looks like Teams is trying to probe for the speed of all the network interfaces based on the paths it is attempting to read.
Is there any way the proper apparmor setup could be part of the "teams" snap or this attempt to read the network interface speed through /sys can be stopped? This is filling up my log files and prevents me from looking up valid log messages of interest.
Here are some example log messages:
[96056.449465] audit: type=1400 audit(1643818317.100:70528): apparmor="DENIED" operation="open" profile="snap.teams.teams" name="/sys/devices/pci0000:00/0000:00:1f.6/net/enp0s31f6/speed" pid=8986 comm="teams" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
[96056.449480] audit: type=1400 audit(1643818317.100:70529): apparmor="DENIED" operation="open" profile="snap.teams.teams" name="/sys/devices/virtual/net/lo/speed" pid=8986 comm="teams" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(284.8, 17%, 37%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EYS%3C/text%3E%3C/svg%3E)
Hi @Matthew Starr ,
The most recent version of the "teams" snap for Ubuntu 20.04 (version 1.4.00.26453) causes constant apparmor messages about attempts to access paths under /sys/ are being DENIED for read access.
By this, do you mean the issue started right after installing the Teams snap for Ubuntu 20.04 (version 1.4.00.26453)? Have you installed older versions of Teams on this machine? Was it working fine?
I tried searching around but so far haven't seen relevant reports involving Teams snap (version 1.4.00.26453). However, during my research regarding the example logs you shared above, I found the link below which includes similar logs although for Skype. According to the information mentioned there, seems like these logs are recorded when the laptop was running out of the battery. So if you are also using a laptop, it's suggested to make sure the laptop is connected to the power cable.
Laptop does not sleep when lid is closed
Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
I just noticed the issue with the current version I listed, but I did not test with older version. I do know that it is filling up my dmesg output and that didn't used to happen a month or two ago.
I am using a Laptop but it is almost always plugged into wall power including when all those log messages were generated. It always has its lid open too when it is plugged in to power. I do not have the laptop setup to automatically suspend or hibernate when connected to wall power.
It looks like the link you provided was someone who was using KDE/Plasma and I am also using the Plasma desktop.
Hi @Matthew Starr ,
that didn't used to happen a month or two ago.
So you meant the current version of Teams had been used without issue for some time until one or two months ago? And no Teams related changes have been made right before the issue started, right? If both are true, seems like some other factors might be involved in this issue.
Aside from the large number of log files, is everything else working fine? If yes, given the fact that it's quite hard to proceed with the information we can collect so far, I am thinking maybe you can consider looking for some method to periodically clean up these logs.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
This spams my dmesg with audit failure attempts at reading the speed of each interface. You can see from the original post that the interfaces are lo and enp0s31f6. It appears to query for speed about every 2 minutes. I have approximately 550 entries in about 2 hours.