What is dataaccessd on macOS?

Last updated: 2026-07-31

What it is

dataaccessd is Apple’s built-in, per-user background process for calendar synchronization. Apple’s supplied dataaccessd(8) manual page calls it a “calendar sync process” and says its job is to synchronize data between local calendars and calendar servers. The manual also says users should not run it manually.

The system executable is located at /System/Library/PrivateFrameworks/DataAccess.framework/Support/dataaccessd, and its launchd identifier is com.apple.dataaccess.dataaccessd. Components supplied with it cover CalDAV, subscribed calendars, holiday calendars, and published calendars. That scope matters because the process name can sound much broader than its actual purpose: dataaccessd is not a general service for collecting data, backing up the Mac, or sending telemetry.

It runs separately from the Calendar application and can be started by launchd when synchronization work is needed. Closing Calendar therefore does not necessarily stop the process or the calendar accounts behind it.

Why it talks to the network

dataaccessd uses the network when a calendar account needs to exchange information with a remote service. This can happen when an account is first added or verified, after an event changes locally or on the server, during a scheduled or manual refresh, or when a push notification reports a remote change. Refreshing a subscribed or holiday calendar can also wake it.

Other triggers include shared-calendar invitations, free/busy requests, changes to shared calendars, and transfers of calendar attachments. These actions do not all represent the same kind or amount of traffic: some may involve only calendar records and protocol metadata, while an attachment or a large subscription can transfer more data.

Its main destinations are the CalDAV or iCloud calendar servers configured by the user, URLs for subscribed calendars, and Apple-hosted holiday calendar services. macOS Calendar also supports accounts such as Google, but Apple does not publicly guarantee that every Google Calendar connection is made directly by dataaccessd.

Exchange should be treated with similar caution. Current macOS installations include a separate exchangesyncd service. Apple has not published a complete division of calendar work between that service and dataaccessd across every system release, so attributing all Exchange calendar traffic to dataaccessd would be unverified.

How much traffic is normal

Apple does not publish a normal byte count, daily baseline, or fixed traffic range for dataaccessd. There is therefore no reliable numeric threshold that can be used by itself to decide whether the process is behaving normally.

When nothing needs to be synchronized, its traffic may be close to zero. Ordinary event changes and routine refreshes usually appear as short, intermittent exchanges containing calendar records and protocol metadata. This is normally much less traffic than photo or video transfers or a system update.

Larger bursts are still possible without proving that anything is wrong. A first synchronization, a full resynchronization, numerous accounts or calendars, a large subscribed-calendar file, or calendar attachment downloads can all increase the amount transferred. Because Apple provides no fixed baseline, a specific daily allowance or byte figure would be speculation rather than a documented standard.

Can you turn it off

You can stop synchronization for a calendar account if you do not need that account’s calendars on the Mac. The supported path is:

Apple menu  > System Settings > Internet Accounts > [account] > turn off Calendar

After Calendar is turned off, that account’s calendars and events stop updating between the Mac and its server. They may also disappear from Calendar on the Mac. Invitations, shared changes, and related notifications will no longer remain synchronized.

This setting must be changed separately for each calendar account. It is an account feature switch, not a master switch for the dataaccessd process. Subscribed calendars or other online calendars that remain enabled may still use the process.

Killing dataaccessd, removing its LaunchAgent, or permanently blocking it is not equivalent to turning off an account cleanly. The system can start the process again, and interference can delay or break updates for calendars, subscriptions, invitations, or attachments.

What people get wrong

• “dataaccessd is a virus, an advertising tracker, or Apple’s general-purpose uploader.” The system instance in Apple’s protected System Library is a calendar synchronization component. A file with the same name found somewhere else should still be checked on its own merits.

• “It synchronizes all mail, photos, files, and cloud backups on the Mac.” Apple’s manual page gives it a much narrower role: calendar synchronization.

• “It is responsible for contact synchronization.” Apple documents iCloud, CardDAV, and Exchange contact synchronization under AddressBookSourceSync, not dataaccessd.

• “Every Exchange calendar transfer definitely goes through dataaccessd.” That conclusion is not supported by the available evidence. macOS has a separate exchangesyncd service, and Apple has not published the complete boundary between the two processes for all system releases.

• “Quitting Calendar stops dataaccessd.” dataaccessd is an independent background process started on demand by launchd. It can continue synchronizing while calendar accounts remain enabled.

• “Killing it, deleting its LaunchAgent, or blocking it permanently is a harmless optimization.” The process can be restarted by the system. Blocking it can cause delayed or failed updates for calendars, invitations, subscriptions, and attachments.

• “It uploads the entire calendar on a fixed schedule.” There is no basis for that claim. The available components support push notifications, manual refreshes, account refresh policies, and synchronization of changes; a scheduled run or wake-up does not prove that a complete calendar was uploaded.

• “A large transfer proves that dataaccessd is broken or stealing data.” A resynchronization, large subscribed calendar, or attachment transfer can create a legitimate burst. Apple supplies no fixed traffic threshold that can establish abnormal behavior from volume alone.

Seeing what it actually used

The next step is to find dataaccessd in Bytetally’s per-process statistics and inspect its traffic over the time period you care about. Compare any burst with known triggers such as an initial sync, manual refresh, subscription update, or attachment transfer instead of relying on an undocumented universal baseline.

Related processes

Common questions