Dropbox: ext4 nie jest ext4

Jakiś czas temu Dropbox zaczął ostrzegać mnie przed obsługą ext4 tylko jako FS. Jako szczęśliwy użytkownik BTRFS nie byłem zadowolony, ale zrobiłem to:

dropbox stop
dd if=/dev/zero of=~/dropbox.img bs=1M count=4096
mkfs.ext4 ~/dropbox.img
echo "${HOME}/dropbox.img ${HOME}/Dropbox ext4 rw,async 0 2" | sudo tee -a /etc/fstab
rm -rf ~/Dropbox/*
sudo mount "${HOME}/Dropbox"
sudo chown "${USER}:" "${HOME}/Dropbox"

Wszystko działało bezbłędnie, ale Dropbox nadal mówi, że powinienem używać ext4 do swojego folderu. Co ja robię źle?

Istnieją trzy rzeczy, których Dropbox wymaga do kontynuowania pracy w systemie Linux, i tylko jedna jest odpowiednio udokumentowana. To, co tutaj podsumowuję, działało dla Dropbox 59.4.93 na Ubuntu 18.04.1 (amd64).

Już pokonałeś pierwszą przeszkodę:

• Podstawowy system plików musi być ext4, a konkretnie nie ecryptfs . tzn. jeśli twój folder domowy jest zaszyfrowany, musisz umieścić folder Dropbox w innym miejscu, np. oddzielna ext4partycja.

Inne rzeczy do sprawdzenia to:

• System ext4plików musi być sformatowany przy pomocy ext_attron. Jest to zachowanie domyślne, ale można to potwierdzić, uruchamiając debugfs -R features /dev/sda1(lub jakkolwiek nazywa się plik urządzenia - jeśli używasz LVM, może to być coś takiego /dev/mapper/computername--vg-partitionname)
• ext4Partycja musi być zamontowany z user_xattrzestawu opcji (można sprawdzić i dodać opcję w dyskach GNOME lub edytować /etc/fstabbezpośrednio)
• Folder docelowy (lub folder synchronizacji Dropbox) musi znajdować się co najmniej dwa poziomy poniżej punktu montowania, jak opisano w tym poście . To oczywiście błąd godny twarzy.

Gdy naprawiłem wszystkie te rzeczy, Dropbox ostatecznie pozwolił mi przenieść folder docelowy, a komunikaty o błędach dotyczące „nieobsługiwanego systemu plików” zniknęły.

Istnieje alternatywa dla twojego rozwiązania - repozytorium GitHub o nazwie dropbox-filesystem-fix . To sprawia, że ​​folder Dropbox wygląda tak, jakby znajdował się w niezaszyfrowanym systemie plików Ext4, bez względu na używany system plików i nie musisz niczego montować, wystarczy uruchomić Dropbox z biblioteką systemu plików Dropbox (LD_PRELOAD).

Musisz pobrać kod z GitHub , skompilować bibliotekę ( make) i zastąpić wpis startowy Dropbox skryptem dropbox_start.py dostarczonym przez dropbox-filesystem-fix.

Jeśli potrzebujesz pełnych instrukcji krok po kroku, sprawdź tę stronę.

Udało mi się to naprawić za pomocą gnome-diskssformatowania partycji ext4 zamiast początkowo za pomocą GParted, a także upewnienia się, że katalog Dropbox został umieszczony na 2-poziomowej głębokości punktu podłączenia partycji. Na 64-bitowym Ubuntu 18.04.1 LTS z Dropbox v60.4.107.

Pełna historia:

1. Na początek stworzyłem dedykowane ext4 z GParted, który został również użyty do zmiany rozmiaru starej partycji, aby umożliwić miejsce dla nowego ext4.

2. Potem starałem się upewnić, że moja konfiguracja spełnia wszystko opisane w odpowiedzi Floriana , ale to nie rozwiązało mojego problemu.

3. Potem, po wielu próbach łączenia różnych rozwiązań, postanowiłem usunąć całą partycję i sformatować ją do ext4 za pomocą natywnego menedżera dysków Ubuntu (zwanego po prostu Dyskami lub gnome-disks), co prowadzi do tego, że Dropbox akceptuje partycję jako ext4!

/etc/fstabDo zamontowania partycji użyłem następującego wiersza :

UUID=ext4_partition_UUID    /media/dropbox  ext4 defaults 0 2

(gdzie ext4_partition_UUIDreprezentuje UUID znaleziony przy ls -l /dev/disk/by-uuid/)

Zauważ, że nie określam user_xattrtutaj opcji.

Mój folder Dropbox znajduje się teraz w /media/dropbox/data/Dropbox- ale nie sprawdziłem, czy głębokość 2 była naprawdę konieczna.

Wydaje się, że coś poszło nie tak podczas formatowania partycji ext4 z GParted zamiast natywnego oprogramowania - nie mam pojęcia, dlaczego i jaka byłaby różnica między nimi. Jeśli ktoś wie, chętnie dowiem się o tym więcej.

Mój laptop instalacyjny Lubuntu 18.10 zaczął narzekać na Dropbox jakiś czas temu, ale dopiero w zeszłym tygodniu odkryłem, że nie ma zainstalowanego pakietu attr . Po zainstalowaniu Dropbox wydaje się szczęśliwy…

Zdarzyło mi się na podstawie artykułu na /unix//a/475253 i próbowałem sprawdzić atrybuty plików w katalogu Dropbox na laptopie. Zaskoczyło mnie, że getfattrpolecenie nie było dostępne, co doprowadziło mnie do zainstalowania pakietu.

To może być dla Ciebie droga naprzód lub może to być zupełnie inny problem, ale mam nadzieję, że warto ją zgłosić.

Dropbox przywrócił obsługę ZFS, XFS, Btrfs i eCryptFS

Dropbox przywrócił obsługę ZFS, XFS, Btrfs i eCryptFS w systemie Linux. Aktualizacja klienta Dropbox przywraca obsługę ZFS i XFS w 64-bitowych systemach Linux oraz eCryptFS i Btrfs we wszystkich systemach Linux.

Spinki do mankietów:

• Dropbox przywraca obsługę ZFS, XFS, Btrfs i eCryptFS w systemie Linux
• Maestral lekki klient Dropbox open source dla systemu Linux

Sprawdź, czy używasz, ecryptfsktóry nie jest obsługiwany :

ecryptfs nie jest obsługiwany, ale Dropbox będzie kontynuował synchronizację z obsługiwanymi systemami plików, które są szyfrowane za pomocą pełnego szyfrowania dysku (np. LUKS)

W Dropbox Linux istnieje sporny błąd, który nie pozwala na umieszczenie Dropbox w folderze nawet w pobliżu ecryptfs

Na przykład miałem ecryptfs /home/user/Dropboxi przeniosłem go ext4 /home/user-unencryptedi nadal nie udało mi się. Musiałem to przenieść ext4 /dropbox/, aby działało. Skontaktowałem się z ich zespołem wsparcia, ale oni nadal sprzeczali się ze mną mówiąc, że ext4 /home/user-unencryptedbyło TAKŻE ecryptfs, ponieważ oboje zaczęli od /home/ Być może mylę się, jak działa ecryptfs, ale nie widziałem żadnych dowodów sugerujących, że wszystko w katalogu / home / było zaszyfrowane, gdy prowadziłem narzędzia do debugowania systemu plików.