web-dev-qa-db-fra.com

Dropbox: ext4 n'est pas ext4

Il y a quelque temps, Dropbox a commencé à me prévenir de la prise en charge de ext4 uniquement en tant que FS. En tant qu'utilisateur heureux de BTRFS, je n'étais pas heureux, 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 fonctionnait sans erreur, mais Dropbox dit toujours que je devrais utiliser ext4 pour son dossier. Qu'est-ce que je fais mal?

21
val

Il y a trois éléments au total nécessaires à Dropbox pour continuer à fonctionner sous Linux, et un seul est correctement 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 plus précisément et non ecryptfs. c'est-à-dire que si votre dossier de départ est crypté, vous devez placer le dossier Dropbox ailleurs, par exemple. une partition ext4 séparée.

Les autres points à vérifier sont les suivants:

  • Le système de fichiers ext4 doit être formaté avec ext_attr on. Il s’agit du comportement par défaut, mais vous pouvez confirmer en exécutant debugfs -R features /dev/sda1 (ou quel que soit le nom du fichier de votre périphérique. Si vous utilisez LVM, il peut s’agir de /dev/mapper/computername--vg-partitionname).
  • La partition ext4 doit être montée avec le jeu d'options user_xattr (vous pouvez rechercher et ajouter l'option sur des disques GNOME ou éditer directement le /etc/fstab).
  • Le dossier cible (ou le dossier de synchronisation Dropbox) doit être au moins deux niveaux sous le point de montage, comme décrit dans cet article . C'est évidemment un bug digne de facepalm.

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 concernant le "système de fichiers non pris en charge" ont disparu.

27
Florian Echtler

Il existe une alternative à votre solution: un référentiel GitHub appelé dropbox-filesystem-fix . Votre dossier Dropbox apparaît ainsi 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 pas à monter quoi que ce soit, il vous suffit d’exécuter Dropbox avec une bibliothèque système de fichiers dropbox (LD_PRELOAD).

Vous devez 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 la page this .

5
Logix

J'ai réussi à résoudre ce problème en utilisant gnome-disks pour formater la partition ext4 au lieu d'utiliser initialement GParted, tout en veillant à ce que le répertoire Dropbox soit placé à une profondeur de 2 niveaux du point de montage de la partition. Sur Ubuntu 18.04.1 LTS 64 bits avec Dropbox v60.4.107.

Le scénario complet:

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

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

  3. Puis, après de nombreuses tentatives pour combiner 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 (simplement appelé Disks ou gnome-disks), ce qui a conduit Dropbox à accepter la partition au format ext4!

J'ai utilisé la ligne suivante dans /etc/fstab pour monter la partition:

UUID=ext4_partition_UUID    /media/dropbox  ext4 defaults 0 2

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

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

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

Il semble que quelque chose a mal tourné lors du formatage de la partition ext4 avec GParted au lieu du logiciel natif - aucune idée de la raison ou de la différence qui les séparerait. Si quelqu'un sait, je serais heureux d'en apprendre plus à ce sujet.

4
Phil

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

Je suis tombé sur l'article à l'adresse https://unix.stackexchange.com/a/47525 et j'ai tenté de vérifier les attributs de fichier dans le répertoire Dropbox de l'ordinateur portable. J'ai été surpris de découvrir que la commande getfattr n'était pas disponible, ce qui m'a amené à installer le package.

Cela pourrait être un moyen d'avancer pour vous ou un problème complètement différent, mais j'espère que cela vaut la peine d'être signalé.

2
Geoff Riley

Vérifiez si vous utilisez ecryptfs qui est non pris en charge :

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

0
y.luis

Un bug controversé dans Dropbox Linux ne vous permet pas de placer Dropbox dans un dossier même near ecryptfs

Par exemple, j'avais ecryptfs /home/user/Dropbox et je l'ai déplacé vers ext4 /home/user-unencrypted et il a quand même échoué. J'ai dû le déplacer vers ext4 /dropbox/ pour que cela fonctionne. J'ai contacté leur équipe d'assistance, mais ils ont continué à se disputer avec moi en disant que ext4 /home/user-unencrypted était AUSSI ecryptfs parce qu'ils avaient tous les deux commencé par /home/ Peut-être que je me trompe sur le fonctionnement d'ecryptfs mais je n'ai vu aucune preuve suggérant que tout se trouvait sous/home/était crypté J'ai exécuté des outils de débogage du système de fichiers.

0
Jonathan