Dropbox: ext4 n'est pas ext4

Il y a quelque temps, Dropbox a commencé à m'avertir de ne prendre en charge ext4 qu'en tant que FS. En tant qu'utilisateur BTRFS heureux, je n'étais pas content, mais je l'ai fait:

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"

Tout a fonctionné sans erreurs, mais Dropbox dit toujours que je devrais utiliser ext4 pour son dossier. Qu'est-ce que je fais mal?

Il y a trois choses au total que Dropbox a besoin pour continuer à travailler sur Linux, et un seul est bien documenté. Ce que je résume ici a fonctionné pour Dropbox 59.4.93 sur Ubuntu 18.04.1 (amd64).

Vous avez déjà franchi le premier obstacle:

• Le système de fichiers de base doit être ext4, et spécifiquement pas ecryptfs . c'est-à-dire que si votre dossier personnel est crypté, vous devez placer le dossier Dropbox ailleurs, par exemple. une ext4partition séparée .

Les autres choses à vérifier sont les suivantes:

• Le ext4système de fichiers doit être formaté avec ext_attron. C'est le comportement par défaut, mais vous pouvez le confirmer en exécutant debugfs -R features /dev/sda1(ou quel que soit le nom de votre fichier de périphérique - si vous utilisez LVM, cela pourrait ressembler à /dev/mapper/computername--vg-partitionname)
• La ext4partition doit être montée avec l' user_xattrensemble d'options (vous pouvez vérifier et ajouter l'option dans les disques GNOME ou modifier /etc/fstabdirectement)
• Le dossier cible (ou dossier de synchronisation Dropbox) doit être au moins deux niveaux sous le point de montage, comme décrit dans cet article . Il s'agit évidemment d'un bug digne d'un visage.

Une fois que j'ai corrigé toutes ces choses, Dropbox m'a finalement permis de déplacer le dossier cible et les messages d'erreur sur "système de fichiers non pris en charge" ont disparu.

Il existe une alternative à votre solution - un référentiel GitHub appelé dropbox-filesystem-fix . Cela fait apparaître votre dossier Dropbox comme s'il se trouvait sur un système de fichiers Ext4 non chiffré, quel que soit le système de fichiers que vous utilisez, et vous n'avez rien à monter, il vous suffit d'exécuter Dropbox avec une bibliothèque de système de fichiers dropbox (LD_PRELOAD).

Vous devrez récupérer le code de GitHub , compiler la bibliothèque ( make) et remplacer l'entrée de démarrage Dropbox par le script dropbox_start.py fourni par dropbox-filesystem-fix.

Si vous avez besoin d'instructions complètes étape par étape, consultez cette page.

J'ai réussi à résoudre ce problème en utilisant gnome-diskspour formater la partition ext4 au lieu d'utiliser initialement GParted, ainsi qu'en m'assurant que le répertoire Dropbox était placé à une profondeur de 2 niveaux du point de montage de la partition. Sur Ubuntu 64.04.1 LTS 64 bits avec Dropbox v60.4.107.

L'histoire complète:

1. Pour commencer, j'ai créé mon ext4 dédié avec GParted qui a également été utilisé pour redimensionner l'ancienne partition pour laisser de la place au nouveau ext4.

2. Ensuite, j'ai essayé de m'assurer que ma configuration répondait à tout ce qui était décrit dans la réponse de Florian , mais cela n'a pas résolu mon problème.

3. Ensuite, après de nombreux essais de combinaison de différentes solutions, j'ai décidé d'effacer toute la partition et de la reformater en ext4 avec le gestionnaire de disque natif d'Ubuntu (juste appelé Disks ou gnome-disks), ce qui a conduit Dropbox à accepter la partition comme ext4!

J'ai utilisé la ligne suivante /etc/fstabpour monter la partition:

UUID=ext4_partition_UUID    /media/dropbox  ext4 defaults 0 2

(où ext4_partition_UUIDreprésente l'UUID trouvé avec ls -l /dev/disk/by-uuid/)

Notez que je ne spécifie pas l' user_xattroption ici.

Mon dossier Dropbox est maintenant situé à /media/dropbox/data/Dropbox- mais n'a pas vérifié si la profondeur de 2 était vraiment nécessaire.

Il semble que quelque chose n'ait pas fonctionné lors du formatage de la partition ext4 avec GParted au lieu du logiciel natif - aucune idée pourquoi ni quelle serait la différence entre eux. Si quelqu'un sait, je serais heureux d'en savoir plus.

Mon ordinateur portable d'installation Lubuntu 18.10 a commencé à se plaindre de la Dropbox il y a quelque temps, mais ce n'est que la semaine dernière que j'ai constaté qu'il n'avait pas le paquet attr installé. Une fois que j'ai installé ça, Dropbox semble être content…

Je suis tombé sur l'article sur /unix//a/475253 et j'ai essayé de vérifier les attributs de fichier dans le répertoire Dropbox sur l'ordinateur portable. J'ai été surpris de découvrir que la getfattrcommande n'était pas disponible, ce qui m'a conduit à installer le package.

Cela pourrait être une voie à suivre pour vous, ou cela pourrait être un problème complètement différent, mais j'espère que cela mérite d'être signalé.

Dropbox a rétabli le support pour ZFS, XFS, Btrfs et eCryptFS

Dropbox a rétabli la prise en charge de ZFS, XFS, Btrfs et eCryptFS sur Linux. Une mise à jour du client Dropbox ramène la prise en charge de ZFS et XFS sur les systèmes Linux 64 bits, et eCryptFS et Btrfs sur tous les systèmes Linux.

Liens:

• Dropbox ramène la prise en charge de ZFS, XFS, Btrfs et eCryptFS sous Linux
• Client Dropbox open source léger Maestral pour Linux

Vérifiez si vous utilisez ecryptfsce qui n'est pas pris en charge :

ecryptfs n'est pas pris en charge, mais Dropbox continuera de se synchroniser avec les systèmes de fichiers pris en charge qui sont cryptés via le cryptage complet du disque (par exemple LUKS)

Il y a un bug contesté dans Dropbox Linux qui ne vous laissera pas mettre Dropbox dans un dossier même près d' ecryptfs

Par exemple, je l'avais fait ecryptfs /home/user/Dropbox, et je l'ai déplacé vers ext4 /home/user-unencryptedet il a toujours échoué. J'ai dû le déplacer ext4 /dropbox/pour qu'il fonctionne. J'ai contacté leur équipe de soutien , mais ils ont continué à discuter avec moi en disant ext4 /home/user-unencryptedétait aussi ecryptfs parce qu'ils ont tous deux commencé avec /home/ peut-être que je me trompe dans la façon dont fonctionne de ecryptfs mais je ne vois pas de preuves pour suggérer tout sous / home / a été crypté quand je courais outils de débogage du système de fichiers.