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?
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:
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:
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
).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
).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.
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 .
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:
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.
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.
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.
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é.
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).
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.