root# drop dropbox

Maak gewoon een loopback image aan voor je dropbox bestanden, formatteer dat als ext4 en mount het naar een pad. Dat pad stel je dan in voor dropbox sync.

https://invent.life/nesity/create-a-loopback-device-with-ext4/.

(Gebruik de tweede instructies onder 'Alternative'. En als je het pad automatisch gemount wil hebben voeg dan een regel toe aan het /etc/fstab bestand.)

Dropbox blij want ze zien 'ext4' en jij kan eender welk bestandssysteem gebruiken voor je systeem.

of heel simpel, duw een ext4/ntfs geformatteerde usb thumbdrive achter in je machine. voor 15 euro ofzo tegenwoordig 64G met usb3 snelheden. kun je ook nog eens de stick met encryptie doen als je perse wilt (omdat je een flexplek heb op werk oid):

https://www.linux.com/learn/easily-encrypt-your-flash-drives-linux

Enige juiste actie. Dropbox biedt weinig gratis opslag, privacy ellende en het werkt ook niet altijd feilloos zodra je bestanden gaat delen.

pCloud is een leuk gratis alternatief. Inclusief Linux support met ook live sync. Alleen voor meer dan 10 Gb en encryptie moet je betalen. Ook beter voor je privacy voor zover ik het nu kan zien. (Zwitsers bedrijf)

Handig als je ervoor gekozen hebt om bijvoorbeeld BTRFS te gebruiken en data die je op dat BTRFS-filesysteem wilt hebben met Dropbox wilt synchroniseren. Dan heb je extra storage en extra handelingen nodig voor een tussenstap via EXT4 of NTFS. Niet handig.

Kennelijk heeft Dropbox extended attributes aangevoerd als reden waarom ze zich tot ext4 beperken, maar dat is kul: alle belangrijke filesystemen op Linux/Unix ondersteunen dat, en vaak beter dan ext4 het doet. Daar komt bij dat ext4 niet overal het default filesysteem is, RedHat en CentOS gebruiken XFS als default, OpenSUSE een combinatie van BTRFS en XFS.

Ik weet niet wat daar achter zit. De gedachte is bij me opgekomen dat het stoms kan zijn als een PHB die in termen van marktaandeel denkt en die ervan overtuigd is dat je moet kijken naar de meest gebruikte filesystemen omdat hij denkt dat elk afzonderlijk filesysteem een hoop inspanning vergt om te ondersteunen. Die manier van denken ben ik in meerdere andere contexten tegengekomen, er zijn mensen die niet lijken te kunnen bevatten dat je vaak 100% marktdekking kan bereiken door je op standaards te richten.

De reden dat ze geen versleutelde bestanden willen zou zijn dat ze aan deduplicatie doen: hetzelfde bestand bij verschillende gebruikers willen ze eenmalig opslaan. Als iedereen z'n spullen versleutelt is elke kopie van hetzelfde bestand volkomen anders.

sure, maar toch doen ze het gewoon en jij hebt een 'take it or leave it'. princiepes tuiten op een forum heeft niet zo veel effect en propbox zal zich niet gaan aanpassen. wel worden je hier enkele opties gemeld om met deze grap om te gaan mocht je echt niet zonder kunnen. ook is dit weer een uitstekend leer momement van een vendor lock in issuetje. vendor vindt iets en jij hebt het maar te accepteren. dat zie je vaker terug bij closed source en minder makkelijk mogelijk bij open source (want die forken dan en geven de rest 'the finger'). dus. leer er van zou ik zeggen en laat je je niet verassen door de volgende vendor grap die ineens telemetry en langdurige met reboot gepaarde brakke updates op vervelende momenten afdwingt bijvoorbeeld?

Wacht eens even! Dit is een DIENST. Een dienst heeft geen "source". Je hebt een gratis file opslag en het boeit niet
of je de source hebt van software die zij of jij gebruiken, want waar het je om te doen is dat is om opslag te hebben
zonder het gedoe van zelf een server regelen. Als je zelf een server zou hebben dan zou je zelf kunnen kiezen wat
voor software je daar op draait maar dat willen veel mensen niet (meer) omdat je dan op die server moet letten en
het ding zelf moet schalen (disk vol, bandbreedte te weinig, etc). Je gebruikt iets als dropbox om dat gedoe niet te
hebben, dus dan is beginnen over source en forken niet relevant.

je gebruikt een closed source client die dadelijk alleen maar ext4 nog maar accepteerd om vage redenen. als nu de client code beschikbaar was, dan kon je die forken en onderhouden zodat die limitatie er niet was en gewoon gebruik bllijven maken van de server API. dat deze closed source client met een server API praat en dat zodoende een dienst geboden wordt, is dus eigenlijk irrelevant. immers die logica die je stelt zou ook impliceren dat websites diensten zijn en dat het MS OS als client die diensten aanbied en als MS ineens besluit in hun edge geen http meer te doen, je dienst toch wel minder verdienstig is en je kunt dan niets meer.

Waarom zou dit bij Dropbox zo zijn? Daar zijn toch wel alternatieven voor waar je zonder al te veel moeite op over kan stappen? Er is pas sprake van vendor lock-in als dat overstappen niet lukt zonder daar extreem veel moeite en/of geld aan te moeten besteden en als er onmisbare dingen niet meer werken zonder die dienst. Zo'n drama is dit nou ook weer niet.

Precies, gewoon overstappen naar een andere dienst. Ik heb goede ervaring met pCloud onder Linux. 10 Gb gratis en een Zwitsers bedrijf. Alleen extra ruimte en encryptie op hun server kost geld. Ik weet alleen niet welke bestand systemen ze ondersteunen maar ik neem aan dat iedereen langzamerhand zijn/haar Linux systeem wel op een ext4 partitie heeft draaien.
Het enige echte nadeel van pCloud is dat ze nog geen 2FA bij weblogin ondersteunen, dat is echt jammer.
Review: https://www.cloudwards.net/review/pcloud/

vendor doet iets, jij moet het maar accepteren en als voor jou om welke reden dan ook, een alternatief niet werkt of issues heeft => zoek het maar uit, je mag je file systeem op ext4 gaan zetten.

was de client open source, dan pak je in dat geval de source van de client en kijkt waarom jou FS eruit gesloopt wordt (en stop het weer terug in de vorm van een patch die je gaat onderhouden) of je pinned je versie en maintained zelf.

ja het is werk, maar het geeft je een extra optie en als genoeg mensen dit doen en er zich een community vormt om die geforkte client, dan zullen vele handen licht werk maken en een duidelijke buisness case aantonen voor propbox. efin, meer opties, meer oplossingen en meer keuzen als de client OSS was geweest.

hoeveel moeite iets kost is namelijk erg afhankelijk van personen die die client gebruiken en hun situaties en dat is een relatieve maat ipv een absolute maat zoals jij lijkt te suggereren. voor jou is het geen drama, maar jij representeert enkel jezelf en misschien iets van je directe omgeving en niet iedereen elders op aard. het blijft altijd moeilijk openminded te zijn en je in kunnen leven in situaties die niet perse op jezelf van toepassing zijn (tip kijk eens naar de mensen bij een NS automaat voor een uurtje en observeer die eens, de NS denk echt dat het rete eenvoudig is voor iedereen en dat elke keer dat het schermpje er weer anders uit ziet, niemand daar issues mee heeft, maar kijk gewoon eens zelf en constateer de blinde vlek van de NS).

https://www.theregister.co.uk/2018/08/14/dropbox_encrypted_linux_support/

kijk ook eens naar de comments. andere mensen andere wensen.

geeft een beetje aan hoe andere mensen dit 'ervaren' en zonder dat ik claim of die mensen zeurpieten zijn of net niet; er zijn mensen die hier issues mee hebben en als het wel OSS was geweest vermoed ik dat een van dit soort mensen al heel vlug een forkje op github had gezet die iedereen had kunnen gebruiken for the time being.

Een OSS client vereist een gepubliceerde - en stabiele - API .

Wanneer een service behoorlijk in ontwikkeling is, is een API die in beton gegoten zit een nachtmerrie - je zit voor eeuwig gebonden aan historische keuzes .

Met een closed API en closed (eigen) client kun je als leverancier enorm veel sneller schakelen, en dingen vanaf een bepaalde dag gewoon uitzetten.

Het komt zo af en toe langs in de Linux kernel - als Linus weer even heel hard erin moet rammen 'we do NOT break userspace' - de API die de kernel garandeert aan user space moet bug voor bug over decennia compatibel zijn.
En over het introduceren van nieuwe user-API calls wordt heel stevig nagedacht omdat de kernel daar inderdaad extreem lange garanties op geeft .
(op de _interne_ API van de kernel zit bewust geen garantie - die wordt veranderd als dat nodig is, en de gebruikers in de kernel worden aangepast. Dat is een mede een belangrijke reden waarom binary modules weinig populair zijn - dan is het de fabrikant die de boel moet aanpassen. Als ze dat niet doen, pech gehad, dan werkt de module na een tijdje niet meer )


En, eerlijk is eerlijk - onder water moet ook Microsoft extreem lang API-gedrag garanderen vanwege de mix van oude en nieuwe servers+clients. (denk SMB ). De ietwat oogkleppen reflex van programmeurs "ja, dat is fout, gaan we herschrijven en dan moet alles maar upgraden want de oude manier is Niet Goed" - daar run je geen business mee.
Dat kan alleen als je zowel de server als de client zijde controleert, en er qua gebruikers mee wegkomt om upgrades erdoor te rammen, en na een bepaalde tijd te stoppen met 'legacy support' . Apple is daar vrij goed in.

Dus vanuit die wens als leverancier kan ik begrijpen dat Dropbox geen open API en open client landschap wenst.


User interface design is serieus moeilijk. Ik weet niet of de NS een blinde vlek heeft, of gewoon weet dat het de eerste keer voor veel mensen even zoeken is en dat het gewoon niet zo heel veel beter kan op een automaat.
(Ook al zal er vast wel een designer zijn die wil ranten hoe het anders moet, ik ben benieuwd hoeveel UI designers werkelijk een land-brede deployment gedaan hebben en echt gemeten hoeveel 'beter' hun UI is dan andere opties ).

De eerste keer dat ik bij een buitenlandse OV-automaat sta kost me ook een tijdje om de UI en logica te begrijpen - ondanks een vrij ruime ervaring elders.

Nee bedankt! Ik houd het bij Btrfs!

The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes.
https://btrfs.wiki.kernel.org/index.php/RAID56
Lekker stabiel....... Mirror zou je nog kunnen gebruiken. Maar voor veel meer zou je dit filesystem niet moeten gebruiken, als je data je lief is.

Leuk geprobeerd. Maar het RAID56 probleem is bekend en beperkt tot wat er staat: parity RAID code. Voor andere gevallen werkt Btrfs prima. Zo goed zelfs dat openSUSE het standaard gebruikt bij installatie. Je kan er je data met een gerust hart aan toevertrouwen.

Toch goed gevoel om hier je data aan toe te vertrouwen...... Geeft toch iets aan van de stabiliteit en kwaliteit van dit product.
Ik vertrouw mijn data liever aan iets wat als stabiel beschreven staat, en waar niet in eens dit soort "foutjes" naar voren komen.

Ik ga wel voor ZFS.....

Btrfs is drama. Een tijdje gebruikt voor een backup volume vorig jaar, maar een filesystem waar je handmatig
opschoonacties op moet doen om ruimte die vrijkomt bij het deleten van files ook werkelijk beschikbaar te maken
voor nieuwe files dat vind ik net iets te 1970 om dat nog te accepteren!

Ik begrijp niet wat er mis is met ext4.

Op zich niks mis met ext4. Echter, features / voordelen van Btrfs: copy-on-write, snapshots, pooling, checksums. Om er maar een paar te noemen.

Heb je door dat je linkt naar wat de ontwikkelaars van btrfs zelf melden? Er is ook nog een pagina waarop ze een overzicht van de stabiliteit van alle onderdelen geven:
https://btrfs.wiki.kernel.org/index.php/Status
Wat jij nu doet is zeggen: OMG er is één onderdeel dat nog niet stabiel is dus alles zal wel een puinzooi zijn. Waarom ga je af op een deel van de informatie en niet op alle informatie? Beoordeel je alles alleen op details waarmee je het onderuit kan halen of kijk je ook wel eens naar het complete beeld?

Het is zeker zo dat btrfs een relatief nieuw filesysteem is en dat het nog in ontwikkeling is. Daarom is het meer dan bijvoorbeeld ext4 een systeem waar je even je huiswerk moet doen voor je het begint toe te passen. Je moet niet alle mogelijkheden die erin zitten blind toe gaan passen maar eerst wat onderzoek doen naar de status ervan. En die is makkelijk te vinden, bovenstaande link was de eerste hit op de zoekactie "btrfs status".

Heb je het over btrfs balance of over wat anders? Ik heb net even een balance op een volume van 2TB uitgevoerd met de filters -dusage=90 -musage=90 en die actie had ruim een minuut nodig. Niet iets om wakker van te liggen. Ik heb het commando in een scriptje staan en voor het zo nu en dan uit, en ik zou er ook een cron job van kunnen maken, de overhead zou niet eens opvallen.

Ik ben btrfs juist vanwege backups gaan gebruiken. Je kan read-only snapshots maken (secondenwerk) en verschillen tussen snapshots tussen btrfs-volumes overbrengen, zodat je een complete backuphistorie kan bijhouden terwijl de backups gemaakt worden in minder tijd dan een tool als unison nodig heeft om alleen te ontdekken wat er veranderd is.

Btrfs is een geavanceerde tool met mogelijkheden waar traditionele filesystemen als ext4 een puntje aan kunnen zuigen, maar geavanceerde tools hebben ook gebruiksaanwijzingen waar je mee moet leren omgaan, btrfs vergt een zekere kennis van zaken. Als je dat niet ziet zitten moet je het niet gebruiken, en als je de voordelen wilt gebruiken moet je wat huiswerk doen. Als je dat niet doet kan je verrassingen meemaken. Als je bijvoorbeeld btrfs gebruikt op een systeem met een dbms of virtual machines op draait dan doe je er goed aan het copy-on-write-mechanisme uit te zetten op de directory's waar de vm-images of dbms-storage staan, anders slaat de fragmentatie je om de oren en valt de performance tegen.

Mijn conclusie is niet dat btrfs een drama is, mijn conclusie is dat jij niet doorhad dat je soms wat kennis van zaken nodig hebt om iets goed toe te passen. Het is helemaal niet erg als btrfs niet jouw ding is, maar als je denkt dat iets in algemene zin een drama is omdat het jou toevallig niet bevalt dan sla je de plank stevig mis.

Die maintenance cron-jobs + scriptjes zijn er ook kant en klaar: https://github.com/kdave/btrfsmaintenance#distro-integration. De default instelling is een keer per week klein (balance) en een keer per maand groot onderhoud (scrub).

btrfs betreffende, ik scrub en rebalance elke week (via cron ergens midden in de nacht ofzo) de 2T raid-1 voor data en metadata btrfs volume (al dan niet op twee LUKS volumes die aan NBDE doen (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-using_network-bound_disk_encryption)).

geen pijn. kost minder dan 2h bij mekaar voor een volume dat nu ~ 1T vol is (50%).

waarom ik voor btrfs gekozen heb is omdat de CoW gebaseerde snapshots geen significante performance hit introduceren zodra je een snapshot hebt gemaakt. dat is met LVM (en daarop dan xfs / ext4) snapshotting wel wel anders! meten is weten.

Ja, en er zullen er wel meer zijn. Maar dit zijn dingen waar ik zelf mee in aanraking wil komen, als je wilt weten hoe balance of scrub zich gedragen moet je er af en toe met je eigen handen aan zitten en zelf de man pages lezen.

Ik ben niet zo kapot van het gemak waarmee vaak abstractielagen worden gestapeld. Als je een tool nodig hebt om de bediening van een tool voor je te regelen dan moet je je onmiddelijk afvragen waarom dat eigenlijk wat toevoegt. Ik zeg daarmee niet dat het antwoord automatisch is dat het niets toevoegt, er zijn zeker goede voorbeelden van dingen die echt iets op een goede manier stroomlijnen, maar ik ben ook voorbeelden tegengekomen die moeilijker waren dan wat ze af probeerden te schermen. Het is belangrijk dat het werkelijk iets toevoegt.

Bedenk dat abstractielagen meestal niet voor de volle 100% erin slagen iets af te dekken, en dat je toch met de onderliggende laag te maken krijgt als er iets misgaat [1]. Dan moet je daar opeens toch thuis in zijn. Als je merkt dat je met de basis ook goed uit de voeten kan dan zou het wel eens zo kunnen zijn dat die extra laag alleen maar onnodige complexiteit heeft toegevoegd aan je systeem en dat je energie hebt gestoken in het leren van de verkeerde dingen.

Met wat ik eventueel in een cron job (of systemd-service met timer) zou zetten op dit vlak denk ik dat geen enkel kant en klaar product van een ander voor mij wat toevoegt.

[1] https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/

Leuk verhaal maar gelukkig totaal niet van toepassing op de voorgestelde btrfsmaintenance scripts.

Heb je dit ook geprobeerd? Werkt het bij jou wel?

Ik heb dit op allerlei manieren geprobeerd, om te beginnen met een ZFS ZVol, maar wat ik ook doe, dropbox blijft mekkeren dat het een unsupported filesystem betreft. Blijkbaar vinden ze een loopback gemounte ext4 ook niet ext4 genoeg.

Ik was een van de eerste gebruikers van Dropbox en heb ze altijd een warm hart toegedragen, maar ik ben er nu klaar mee.

Zal ik dan toch maar switchen naar pCloud?

pCloud werkt uitstekend in Linux, spreek uit ervaring. Ook beter voor je privacy denk ik zelf. Inmiddels hebben ze ook een beperkte 2FA, dat ontbrak tot voorkort. Helaas wel via telefoonnummer en niet via OTP.

pCloud was het ook niet:

* Buggy client op Android.
* Vage X-only static binary voor Linux (maar wel goed verstopt een veel betere via GIT)
* Autosync? Okay, maar dan ga ik ook die 1200 foto's van je SD card uploaden
* Zeer irritante "Upgrade To Premium" overal waar je kijkt
* Encryptie alleen tegen betaling
* Van de 10G kreeg ik maar 7G. De laatste 3G zou ik verdienen door 3 anderen succesvol te spammen.

Maar de druppel was wel:

* Meerdere notifications met een Black Friday aanbieding.

Jammer dat ze niet vroegen waarom ik mijn account ging wissen.

Maar wat dan wel?

Voorlopig ben ik erg tevreden met NextCloud op mijn eigen server. Terabytes storage zonder gezeik!

En als die server uit je huis gestolen wordt ben je al je data kwijt...

Als ik geen andere maatregelen had genomen, was dat bij pCloud (op 7 GB na) ook zo.

Vertel: Wat ging er mis bij pCloud? Ik heb er ook een backup staan...

Restic met Backblaze.

https://help.backblaze.com/hc/en-us/articles/115002880514-How-to-configure-Backblaze-B2-with-Restic-on-Linux

Er ging niks mis bij pCloud, maar ik vond ze erg vervelend opdringerig. Zie ook 05-12-2018, 11:49.

Ik heb er geen backup staan en had daar ook geen backup staan. 7GB is wat weinig voor een backup. Ik snap dus niet waarom die Anoniem van 05-12-2018, 16:00 denkt dat ik een probleem heb als mijn server gejat wordt. Als mijn server gejat wordt, zou ik ook met pCloud (en 7GB) data een probleem hebben. Ik heb mijn remote backup allang geregeld, daar heb ik geen clouddienst voor nodig.

Ik had wel een clouddienst nodig voor het delen van bestanden en het syncen van mijn Android telefoon. Nextcloud blijkt daarin heel goed te passen bij mijn requirements.