Skip to main content
Question

CoreTelephony error, as a result of /tmp becoming unwriteable

  • November 17, 2016
  • 3 replies
  • 24 views
B
Forum|alt.badge.img+7

I'm getting an increasing number of macs in my environment that are exhibiting this strange problem, whereby suddenly the /tmp folder (/private/tmp) is becoming unwriteable.
Obviously this causes various odd problems with apps as a result, the most visual being an Apple error on login: "CoreTelephony Trace File Error, a file operation has failed, you may be out of space".
This error itself is a red herring, and is only indicative of the /tmp folder not being writeable.

Booting into recovery mode, disabling SIP, then recreating the /tmp folder with the correct permissions appears to fix the issue (as per discussions here: http://www.macosxblog.com/how-to-fix-coretelephony-trace-file-error-on-mac/ )

However, the problem is that I can't find out what it is that's causing the issue.
I've spent considerable time perusing all of the system log files, and can't find any indication of the cause, other than errors as a result of the OS not having permission to write to /tmp

Machines affected so far have all been on 10.11 (10.11.3, 10.11.5, and 10.11.6)

Any insight/suggestions on this, or feedback from anyone else experiencing this problem in an enterprise environment would be appreciated.
The "fix" is all well and good for home users, but I'm concerned that this issue is becoming more prominent here, amongst our 600 or so enterprise mac users.

Many thanks in advance.

    3 replies

    AVmcclint
    Forum|alt.badge.img+21
    • AVmcclint
    • Esteemed Contributor
    • November 17, 2016

    What are the permissions being changed to? Do you have any packages/policies that put pieces inside /tmp and somehow that's what is changing the permissions?

    B
    Forum|alt.badge.img+7
    • benshawuk
    • Author
    • Contributor
    • November 17, 2016

    Permissions look the same, apart from an extra @ on the affected machine, which I believe refers to "extended attributes" of some kind:

    Affected mac:
    drwxrwxrwt@ 3 root wheel 102 4 Oct 06:10 tmp

    Working mac:
    drwxrwxrwt 17 root wheel 578 17 Nov 13:45 tmp

    The /tmp folder on affected macs appear to be empty, except for a folder called "noticeboard".
    This seems to be related to preferences surrounding the "Upgrade to sierra notification" message that pops up. Ironically, I posted on here asking if anyone had a method of blocking this alert notification, but I certainly didn't ever attempt anything to do so.

    Also, if SIP is supposed to affect the /private/tmp folder, then how is anything able to write within it?
    Also, how would any process/pkg/script be able to cause enough damage to screw up the permissions on it?

    To answer your other question: I do have lots of packages and scripts that run periodically and install things etc., but I can't see anything amongst those that would cause this. Also, there are obviously hundreds of machines (most) that are currently unaffected by this issue.
    When scripting/installing in my own scripts, I avoid using the built in /tmp folder anyway (I use my own temporary folder elsewhere on the file system).

    B
    Forum|alt.badge.img+7
    • benshawuk
    • Author
    • Contributor
    • November 17, 2016

    Update:
    ls -leO@d /private/tmp

    displays this on an affected mac:
    drwxrwxrwt@ 3 root wheel restricted 102 4 Oct 06:10 /private/tmp com.apple.rootless 0

    So basically, something is making that folder "rootless", which explains why SIP is stopping write access to it as root (and why the fix works).
    My only pressing question now, is what is causing this?!

    Terms & ConditionsCookie settingsAccessibility statement