Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ending support for Dropbox syncing to drives with certain uncommon file systems

dropboxforum.com

Post reply on HN
Print view View original

421–429 of 429 posts

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#421

Post by bobpaul »

Spivak wrote: post #341
mjevans wrote: post #329

Earlier quoted context omitted.

For such systems I consider the primary root file-system to be part of the 'bootloader'. Everything that I want to keep actually secure is inside of the encrypted PVs backing LVM volumes. Yes, this presents a security risk in that someone could (offhand I think the term is 'evil maid'?) attack the root filesystem, but they could still have done that to the bootloader anyway. Remote interaction is then required to bri…

They could not have done that to the bootloader because of SecureBoot.

With secureboot on Linux you can secure as much or as little as you want. On my system, grub isn't even safe, only the shim that load grub is secure. But I could set it up so the kernel is secure, have the kernel only load verified initrd, and then have the initrd check the root filesystem.

I don't, but secureboot can detect changes to the root filesystem if you want it to. I think this generally requires setting the rootfs to mount readonly.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#422

Post by swiley »

jonknee wrote: post #129
swiley wrote: post #90

Earlier quoted context omitted.

Just use syncthing. It works better, is open source, and runs on everything.

I guess you could say it runs of everything unless you use one of the two most popular operating systems in the world: Android and iOS.

It runs very well on android with termux.

Like most open source software: don't bother with the "apps" just install it in termux the same way you would on any other computer.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#423

Post by azinman2 »

vxNsr wrote: post #366
azinman2 wrote: post #360

Earlier quoted context omitted.

What makes you say onedrive is better than Dropbox?

Because of its close integration with Office 365, and it's cheaper.

You said it wasn’t the best file syncing... office 365 integration doesn’t seem to suggest that one drive is a better file syncer... especially because Microsoft owns office. I’d expect that. Gdrive does Gsuite integration, but I wouldn’t knock other services for not having that.

I’ve seen many other services have major issues syncing files... dealing with conflicts, corruption, random file types like issues around Mac resource forks and file-folder types, etc. I’ve seen weeks of work get lost because gdrive stopped syncing, then when resuming overwrote all of a colleagues updated files.

Dropbox has solved all such problems.. in part because they’be been around forever, but also because they’ve hired great talent to do nothing but sync. I trust them way more on that core competency.

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#425

Post by spacenick88 »

Vash63 wrote: post #139
gnufied wrote: post #64

Earlier quoted context omitted.

I would hold my horses on xfs being unsupported claim. They explicitly said any modern file system with xattr is supported. XFS does fit that description. OP has drawn his own conclusions from the Dropbox reply.

My /home is XFS on my Arch system and I received the same popup from the Dropbox client. I can confirm that this does apply to XFS as well.

Same for Btrfs

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#426

Post by Rondom »

StavrosK wrote: post #368
ronjouch wrote: post #245

Earlier quoted context omitted.

Indeed: https://wiki.ubuntu.com/BionicBeaver/ReleaseNotes#Other_base... > "The installer no longer offers the encrypted home option using ecryptfs-utils. It is recommended to use full-disk encryption instead for this release."

Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.

Debian and Ubuntu allow running Dropbear in initramfs to prompt for the FDE password

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#427

Post by StavrosK »

Rondom wrote: post #426
StavrosK wrote: post #368

Earlier quoted context omitted.

Shit, so now I can't turn on my desktop remotely and supply the password through SSH later? That's a huge inconvenience.

Debian and Ubuntu allow running Dropbear in initramfs to prompt for the FDE password

That's fantastic to know, thank you. Do you know if it's complicated to set up?

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#428

Post by culot »

thomasfedb wrote: post #420
culot wrote: post #303

Earlier quoted context omitted.

Onedrive handles Git repos on Windows fine. It does balk sometimes if you feed it large repos, but most often it works fine.

This just sounds like a horrible scary idea. What happens if I change something in a repo on multiple machines - a OneDrive merge conflict inside .git sounds like a nightmare.

I hadn't thought of that, that indeed sounds torturous!

Re: Ending support for Dropbox syncing to drives with certain uncommon file systems

#429

Post by colint »

shittyadmin wrote: post #393
MikeHalcrow wrote: post #356

Earlier quoted context omitted.

Author of eCryptfs and EXT4 encryption chiming in. "Series of issues?" Really? There were 3, and they were all scored "Low" by the authors for exploitability and security impact. That said, I generally agree FDE is the way to go if your platform's constraints allow for it -- but only for security. Native EXT4 encryption will give you equal or better performance than FDE primarily because the file system metadata isn'…

Ah, you're right, I had it confused with a similar analysis on EncFS which had more significantly damaging findings. https://defuse.ca/audits/encfs.htm I wasn't even aware Ext4 had native encryption support though! I'll definitely have to give that a go. Thanks for the tip.

According to Michael Halcrow's LinkedIn [1], he was heavily involved on the EXT4 encryption:

"I was also the project lead for encryption in EXT4, which is now available as the mechanism implementing file-based encryption on Android."

[1] https://www.linkedin.com/in/michael-halcrow-1880601

Post reply on HN