Wat is cloudd op Mac? De iCloud Sync Daemon uitgelegd

cloudd is de CloudKit-daemon: het proces dat macOS gebruikt om namens apps met Apple's iCloud-servers te praten. Het is een standaardonderdeel van macOS, geleverd en ondertekend door Apple, en het is geen malware.

CloudKit is Apple's framework om app-gegevens in iCloud op te slaan en ze consistent te houden op de apparaten van een gebruiker. Apps openen niet hun eigen verbindingen om te synchroniseren; ze geven hun gegevens aan CloudKit, en cloudd doet het werk van wijzigingen uploaden, wijzigingen ophalen die op andere apparaten zijn gemaakt, en mislukte verzoeken opnieuw proberen.

Er loopt meer via dit proces dan de meeste mensen verwachten. Documentensynchronisatie via iCloud Drive verloopt erdoorheen, net als Notities, en Foto's gebruikt het voor bibliotheekmetadata. Veel van Apple's eigen apps vertrouwen erop om consistent te blijven tussen een Mac, een iPhone en een iPad, en dat geldt ook voor een groot aantal apps van derden: CloudKit is een populaire synchronisatiebackend omdat de ontwikkelaar geen eigen server nodig heeft.

Dus wanneer cloudd actief is, kijk je bijna altijd naar iCloud-synchronisatie die bezig is, voor het systeem, voor een Apple-app of voor iets dat je hebt geïnstalleerd.

Dit is het meest nuttige om te begrijpen over cloudd, en de bron van bijna alle verwarring eromheen.

cloudd is een gedeelde koerier. Het genereert geen verkeer op een betekenisvolle manier; het vervoert data van andere apps. Wanneer een notitie verandert, wanneer een document in iCloud Drive terechtkomt, wanneer een derde-partij takenbeheerder een item synchroniseert, verlaten die bytes je Mac onder de naam van cloudd in plaats van onder de naam van de app die ze heeft geproduceerd. Elk hulpmiddel dat netwerkactiviteit per proces toewijst, inclusief Activity Monitor, zal daarom een groot getal tonen voor cloudd en weinig voor de apps die er daadwerkelijk verantwoordelijk voor zijn.

Dus dat cloudd veel data gebruikt, zegt zelden iets over cloudd zelf. Het zegt iets over hoeveel je apps synchroniseren, samengevoegd in één regel. Twee Macs die identieke kopieën van macOS draaien, kunnen heel verschillende cloudd-getallen laten zien, puur omdat de ene een grote Photos-bibliotheek heeft en een paar CloudKit-ondersteunde apps.

macOS doet dit ook elders: nsurlsessiond verzorgt achtergronddownloads en uploads voor andere apps en lijkt zwaar te zijn om dezelfde reden. Zodra je het patroon herkent, stopt een drukke daemon met een generieke naam niet meer met alarm slaan. Het is meestal een pijp, en de interessante vraag is wat er doorheen wordt gepusht.

cloudd is veilig. Het is een first-party Apple-daemon, het maakt al jaren deel uit van macOS, en het gedrag wordt volledig verklaard door de taak die het uitvoert. De terechte vraag is niet of de echte cloudd gevaarlijk is, maar of het proces dat onder die naam op je Mac draait echt is. Een begrijpelijke vraag, want een saaie systeemachtige naam kiezen is een oude truc.

Je kunt dat zonder speciale tools vaststellen. Zoek in Activiteitenweergave cloudd op en open de inspecteur door erop te dubbelklikken. De echte daemon zit in het alleen-lezen systeemvolume en niet in je thuismap, Applications of Downloads, en wordt gestart door launchd in plaats van door iets wat je zelf hebt geopend. Een proces dat cloudd heet en uit een gebruikersmap draait, zou de afwijking zijn die het waard is om uit te zoeken.

De sterkere controle is de codehandtekening. De systeembinaries van Apple zijn ondertekend door Apple, en op moderne macOS is het systeemvolume cryptografisch verzegeld, dus een vervangen systeemdaemon is niet iets wat gewone software stilletjes kan regelen. macOS wordt geleverd met command-line tools die de ondertekenaar van elke binary rapporteren, en voor cloudd zou dat Apple moeten zijn.

Het is ook goed om te zeggen wat cloudd niet is. Het is geen analytics- of telemetrieproces, het verplaatst de gegevens van je apps naar en van iCloud voor de diensten die je al hebt ingeschakeld.

Zware activiteit van cloudd betekent bijna altijd dat er een grote synchronisatie gaande is, en de meest voorkomende situatie is de eerste. Een nieuw ingelogd iCloud‑account, een frisse installatie, of een dienst die je net hebt ingeschakeld, moet alles vanaf nul reconciliëren, wat uren kan duren en veel gegevens kan verplaatsen. Een grote Photos‑bibliotheek is het klassieke voorbeeld; zo is een grote iCloud Drive‑map die net is toegevoegd of hersteld. De juiste reactie is meestal geduld: laat het op een verbinding staan waarop de gegevens niet uitmaken, en de activiteit valt vanzelf terug naar een trage stroom.

De tweede oorzaak is een synchronisatie die blijft falen en opnieuw probeert. Als een item niet kan worden geüpload, probeert cloudd het mogelijk in een lus, wat lijkt op langdurig CPU‑gebruik zonder dat er iets uitkomt. De aanwijzing is activiteit die nooit tot rust komt, over dagen in plaats van uren, zonder grote overdracht om het te verklaren. Een herstart lost een groot deel hiervan op; als dat niet helpt, is het meestal voldoende om de betreffende service uit te schakelen en weer in te schakelen in de iCloud‑instellingen, of uit te loggen en opnieuw in te loggen op iCloud.

Ten derde: controleer wat daadwerkelijk is ingeschakeld. De iCloud‑instellingen tonen welke services en apps synchroniseren, inclusief third‑party apps, en het uitschakelen van synchronisatie voor een app die je zelden gebruikt, vermindert de belasting volledig.

Bij een metered‑verbinding is het probleem niet dat cloudd druk bezig is, maar dat druk bezig zijn geld kost. Het antwoord is nog steeds niet om het te blokkeren: pauzeer iCloud‑synchronisatie, zet Low Data Mode aan voor dat netwerk, schakel de zwaarste services uit terwijl je erop zit, of beperk het verkeer.

cloudd blokkeren met een firewall is mogelijk, en het is een slecht idee om één specifieke reden: het verbreekt iCloud-synchronisatie door het hele systeem, en dat gebeurt stilletjes. Niets geeft een foutmelding weer. Notities verschijnen niet meer op je andere apparaten, documenten stoppen met bijwerken, apps van derden worden stilletjes verouderd, en weken later ben je aan het uitzoeken waarom een wijziging die op je Mac is aangebracht nooit op je iPhone is gekomen. Het mechanisme is niet het ding om aan te vallen; het volume is dat.

Wat overblijft is het echte probleem: zichtbaarheid. macOS draait veel daemons die zonder te vragen verbinding maken met het netwerk, de meesten met namen die niets prijsgeven, en het biedt bijna geen manier om te zien welke ervan waar mee verbinden of hoeveel ze verplaatsen. Wanneer er een bovenaan een bandbreedtelijst verschijnt, is er geen ingebouwde manier om te beoordelen of dat normaal is.

Die kloof is wat NetMute sluit. Het toont realtime per-app en per-proces verkeer, en logging op domeinniveau registreert welke domeinen elk proces heeft benaderd en hoeveel data ermee gemoeid was. Voor het geval van metered data (verbruikte data) zijn per-app datalimieten het praktische hulpmiddel: een dagelijkse of maandelijkse limiet per proces, een waarschuwing bij een door jou gekozen drempel, en een automatische blokkering bij 100 procent, met een globale limiet erboven en limieten opgeslagen per netwerkprofiel, zodat je hotspotregels niet je thuisregels zijn. Profielen schakelen automatisch mee met het Wi‑Fi-netwerk waarmee je verbindt, en de per‑app firewall blokkeert alles dat niet zou moeten communiceren met één klik, met tijdelijk geldende regels voor testen die vanzelf verlopen.

Het doel is niet om meer te blokkeren. Zoals cloudd laat zien, is het meeste achtergrondverkeer op een Mac legitiem. Het doel is het verschil te kunnen zien, en het binnen een budget te houden wanneer de verbinding die je gebruikt er één heeft.