Antag att jag har en IoT-enhet som styrs av företag A och som köper en massa tjänster från företag B. Jag kommer att vara ansvarig för alla avgifter, även om jag inte hade någon aning om att företag A skulle göra dessa inköp för min räkning.

Under helgen upptäckte jag att jag har en sådan enhet och att de pengar som riskerar att hamna på spel inte är obetydliga. En bakgrundsprocess kallad nsurlsessiond som Apple använder för att hantera iCloud-tjänster hämtade 400 GB (ja, GIGA och ja BYTES) data till min iMac under loppet av 31 timmar. Apple gör det mycket svårt att se eller förstå vad den här processen gör. Så i praktiken förvandlades min iMac till en IoT-apparat som förbrukade bandbredd.

Jag fick reda på att det fanns ett problem bara för att jag tillbringade lite tid med att arbeta på distans på min Macbook och använde min iPads 4G-anslutning till internet. Den hade också förvandlats till en av dessa IoT-apparater, så jag fick snart en varning från min internetleverantör som sa att jag redan hade överskridit hela min månatliga tilldelning på 20 GB nedladdad data via trådlöst nätverk. Jag slutade ansluta via 4G så fort jag kunde, men fick ändå betala 75 dollar i överskottsavgifter för data.

När jag kom hem kontrollerade jag min iMac. Jag kunde inte hitta något sätt att få den information jag behövde för att ta reda på vad som pågick från den inbyggda aktivitetsövervakaren. Som tur är kör jag också ett program som heter Little Snitch som övervakar nätverkstrafiken. Dess rapport om nsurlsessiond visade detta:

nsurlsessiond

För att kvantifiera ansvaret här, om denna nedladdning hade skett via min 4G-anslutning skulle min internetleverantörs övertrasseringsavgift på 15 dollar per GB, multiplicerad med 400 GB data, innebära 6000 dollar i dataavgifter. Min anslutning hemma har inget datatak, men det är inte alla som har detta skydd. Teknikern på Apple sa att om jag skulle drabbas av stora avgifter fungerar det ibland att ringa internetleverantören och be om nåd.

Apple och min internetleverantör har ett långvarigt förhållande. Tillsammans har de ett gemensamt intresse av att få mig att använda mycket mer data som internetleverantören kan ta betalt för. Min internetleverantör kan belöna Apple genom att uppmuntra försäljningen av Apples mobila enheter.

Men förmodligen vill de båda undvika en uppmärksammad användningstopp som den jag råkade ut för. Den orsakades säkert av en bugg. Men det är talande att Apple har konfigurerat saker och ting så att jag som standard inte har någon insyn i dataförbrukningen i bakgrunden och utan någon strypning eller begränsning som skulle kunna begränsa den potentiella skadan som när saker och ting spårar ur.

Om du måste betala för data ska du vara mycket försiktig med att använda iCloud. Och gör dig redo för många överraskningar från IoT.

För alla som står inför ett liknande problem med nsurlsessiond

Sammanfattning

  1. Om du behöver en tillfällig lösning som stoppar de massiva datahämtningarna är ett alternativ att installera Little Snitch och lägga till en regel som du kan aktivera och inaktivera och som nekar alla utgående anslutningar till nsurlsessiond. Detta stoppar visserligen bara de utgående förfrågningarna, men det verkar vara nödvändigt för att upprätthålla de inkommande nedladdningarna.

  2. För att få en permanent lösning var jag tvungen att sluta använda iCloud helt och hållet. Jag raderade alla data från iDrive och jag raderade alla data från det enda program (Notability) som hade tillstånd att lagra data i iCloud.

  3. Om du, som jag, har ett problem som är en riktig bugg och inte en inbyggd funktion i Photos – stora dataöverföringar om du har ett stort fotobibliotek och går med på att använda Photos med iCloud – kommer du att behöva spendera mycket tid och möda på att kontakta Apples tekniska support för att övertala dem att Photos inte är källan till ditt problem.

Detaljer

1. nsurlsessiondDet finns många rapporter om användare som hamnat med enorma nedladdningar som de inte hade räknat med. Många av rapporterna från mer tekniska användare identifierar nsurlsessiond som den process som utförde nedladdningen. Många av dessa är uppenbarligen resultatet av standardinställningar och ett vilseledande gränssnitt som får människor att gå med på att lagra stora mängder fotodata i iCloud utan att inse konsekvenserna av detta beslut. Jag var noga med att inte låta något av Apples program använda iCloud. För att göra detta var jag tvungen att ändra standardinställningarna för iCloud, vilket aktiverar Apples program.

2. iCloud DriveSom en del av iCloud har jag använt iDrive, som låter mig ha en del av mitt filsystem i molnet. Jag kan se dessa filer i Finder under iCloud Drive. Detta beter sig som Dropbox eller Google Drive, men med en avgörande skillnad. Jag har ingen kontroll över synkroniseringsprocessen med det lokala datalagret. Om iDrive är aktiverat synkroniserar en bakgrundsprocess (förmodligen nsurlsessiond men det kan finnas andra) filerna på iDrive med en cache på min maskin. Jag hade ungefär 30 GB data på iDrive.

3. Låta ett program använda iCloudJag låter bara ett program (Notability) lagra sina data i iCloud. Den här appen körs på både IOS-enheter och OSX. Under OSX innebär även detta en synkronisering mellan de data som lagras i molnet och en lokal cache. Skillnaden är att som man kan förvänta sig från IOS-världen är filerna inte synliga via Finder. När jag kontrollerade iCloud under Systeminställningar kunde jag se att Notability lagrade cirka 3 GB på iCloud. (Detta är mycket mer än vad Notability verkar vara konstruerat för att hantera. Denna stora mängd data uppstod delvis på grund av att Notability på en IOS-enhet duplicerar varje anteckning om du stänger av iCloud-åtkomsten och sedan slår på den igen. Tydligen förvandlar avstängningen den lokala cachen till ett permanent lokalt datalager. Om du sedan slår på iCloud igen laddar Notability ner en ny kopia av varje anteckning från iCloud och lägger dem i en ny cache. När jag försökte felsöka problem med Notability slutade jag med 4 kopior av varje anteckning.)

4. Källan till mitt problemJag såg indikationer på buggar i både Notability och iDrive så jag är inte säker på vad som orsakade de massiva nedladdningarna.

Cachelagringsfilerna ligger under användarbiblioteket, som du kan komma åt via Finder genom att hålla ner alternativtangenten när du klickar på Gå. För att se vad som händer i biblioteket hjälper det att välja Visa visningsalternativ för Finder (från menyn Visa) och markera Beräkna alla storlekar så att Finder kan visa storleken på alla mappar i en katalog.

I biblioteket verkar mappen Mobila dokument vara cacheminnet för iDrive. Den hade samma mängd data, 30 GB, som jag ursprungligen laddade upp till iDrive.

Jag misstänker att Notability cachelagrade information i Library/Caches/CloudKit. Vid olika tillfällen hamnade den här mappen på något mellan 5 och 20 GB, vilket naturligtvis är alldeles för mycket i förhållande till de 3 GB som Notability skulle hantera. Om man tar de två tillsammans finns det ingen anledning till varför synkronisering av totalt 30+3 GB data skulle kräva 400 GB nedladdningar till en enda maskin. Något måste ha fortsatt att försöka, om och om igen, att åstadkomma något som inte fungerade.

Den stora cachen i CloudKit tydde på att Notability var problemet. Jag försökte ta bort mappen CloudKit och till och med hela mappen Caches. När dessa låg i papperskorgen användes de fortfarande av olika systemprocesser. Efter en omstart såg jag ibland en stor cache återuppstå under CloudKit alltför snabbt för att detta skulle vara resultatet av nedladdningar, så jag misstänker att samma processer som hade använt filerna när de låg i papperskorgen återställde dem till CloudKit efter en omstart. Det enda sätt jag hittade för att förhindra detta var att i) stänga av min internetanslutning, ii) radera CloudKit-mappen, iii) starta om, iv) tömma papperskorgen, v) slå på internetanslutningen igen. Men då verkade CloudKit-cachen fortfarande fortsätta att återuppbygga sig själv via en nedladdning. Detta verkade fortsätta även efter att jag raderat alla mina data från Notability. (I efterhand borde jag ha försökt radera denna cache från både min iMac och min MacBook för att utesluta möjligheten att cacheminnet på den ena maskinen försökte återuppbygga cacheminnet på den andra.)

Mina problem löstes först efter att jag också raderat alla mina data från iDrive, och gjort detta på varje maskin och för varje användare med tillgång till iDrive. På vägen dit försökte jag också flera gånger till att radera CloudKit-cachemappen. (Den har nu väldigt lite data.)

Min föraning är att Notability var boven i dramat, men det är möjligt att iDrive också använde CloudKit-cachemappen på något sätt och att det var den verkliga källan till problemet; eller att det finns någon växelverkan mellan Notability och iDrive; eller att det fanns en fördröjning eller en växelverkan mellan cachemapperna på de två maskinerna, så att det löste problemet att göra mig av med Notability-datan, men det visade sig inte förrän efter det att jag hade raderat all data från iDrive; eller …

Lämna ett svar

Din e-postadress kommer inte publiceras.