[1fichier] "Montez" votre stockage 1fichier en une commande simple !

Zakhar · Le 13/09/2025, à 22:29

Jarodd a écrit :

Je fais mes synchros avec rsync (ou GUI équivalent). Je ne devrais donc pas l'utiliser, mais passer par cp et transférer mes fichiers un par un ? En attendant entre 2 transferts ?
Dans .upload.1fichierfs, j'ai 9 répertoires pour 6.47 Mo au total. J'ai transféré bien plus que ça. Ces nombres correspondent à ce que j'ai réellement uploadé ? Le reste s'est donc "perdu" car les transferts étaient trop rapides ?

Je constate ce soir qu'un fichier de ~20Go que j'ai uploadé n'est plus sur le serveur FTP et n'est pas non plus sur le stockage, et ce depuis largement plus d'une heure.

Je vais tout de même faire un rapport à 1fichier.com des fois que ce soit un "bug récent" du mécanisme d'upload en FTP.

Jarodd · Le 14/09/2025, à 10:28

Bonjour,
Je n'ai pas encore pris le temps de refaire les tests, suite à tes derniers posts. Je vais attendre que tu aies un retour pour les faire.

Zakhar · Le 14/09/2025, à 18:15

Oui, j'ai fait un rapport, ils m'ont demandé des précisions.

J'ai envoyé un fichier d'environ 20Go à 22h04 (fin du transfert), il est arrivé sur le stockage à 0h12.

S'il a fini par arriver... on peut au moins dire qu'il s'agit d'une extrême lenteur. J'attends le retour... mais on est dimanche.

Dernière modification par Zakhar (Le 14/09/2025, à 18:16)

Jarodd · Le 14/09/2025, à 19:06

De mon côté je n'ai toujours aucun fichier dans l'interface 1Fichier, 10 jours après les premiers tests. Je suppose qu'on peut considérer que cela n'a pas fonctionné Je retente les transferts demain.

Dernière modification par Jarodd (Le 14/09/2025, à 19:07)

Zakhar · Le 14/09/2025, à 19:10

Jarodd a écrit :

De mon côté je n'ai toujours aucun fichier dans l'interface 1Fichier, 10 jours après les premiers tests. Je suppose qu'on peut considérer que cela n'a pas fonctionné Je retente les transferts demain.

Haha oui, 10 jours !..

Mais pour éliminer le problème "rsync" qui est un peu délicat avec 1fichierfs à cause des limitations de l'écriture, fais plutôt le test avec une copie simple, soit par commande en ligne (cp) ou via Nautilus/Fichiers/Dolphin selon le gestionnaire de fichiers de ta distribution.

Après, si ça marche en "copie simple", tu peux essayer avec ton logiciel GUI-rsync favori. Là si ça merde, il faut me donner des détails sur le logiciel utilisé, les manipulations réalisées, pour que je puisse éventuellement reproduire.

Jarodd · Le 15/09/2025, à 11:41

Bonjour,
Quand je lance une comparaison de mes fichiers avec le contenu de /media/jarodd/1fichier (mon répertoire monté), je vois toujours les fichiers copiés il y a 10 jours. Donc rien n'est à synchroniser. Que dois-je faire ? Faut-il faire un rm-rf sur le contenu de ce répertoire ? Ou supprimer autre chose pour vider le cache ?

Zakhar · Le 15/09/2025, à 19:00

Non, non, il n'y pas de "cache", juste des marqueurs pour la "reprise" si tu as arrêté le PC avant que le cycle côté serveur 1fichier.com ne soit terminé !..

Les fichiers uploadés vont dans .upload.fichierfs, tu peux donc faire :

ls -al /media/jarodd/1fichier/.upload.1fichierfs/
total 8
dr-xr-xr-x 2 jarodd jarodd 4096 mars  19 11:27 ./
drwxrwxr-x 2 jarodd jarodd 4096 déc.   5  2020 ../

Si c'est vide, comme montré ci-dessus (juste . et .. qui sont toujours présents), c'est que tout est correct.
S'il reste des choses qui datent de ton test il y a 10 jours, tu peux tout effacer dans ce répertoire pour "nettoyer". Il est possible que ça te refuse certains effacement, auquel cas il faut le faire avec l'interface web.

Il te faut donc recommencer l'upload, de préférence avec une copie simple : gestionnaire de fichier ou cp.

Tu peux supprimer le peu que tu as uploadé pour recommencer propre si tu veux, et pour éviter des éventuelles questions du gestionnaire de fichier sur l'écrasement des fichiers déjà présent.

Si ça fonctionne ainsi, c'est soit que ton utilitaire-rsync fait des choses non possibles pour 1fichierfs... et qu'il ne t'a pas prévenu des erreurs !..
Soit que la façon de faire les choses de ton utilitaire crée un bug. Dans ce cas ça m'intéresse d'en savoir plus pour corriger... mais pas avant que tu n'aies vérifier le fonctionnement avec une "copie simple", parce que ça on sait que ça marche parfaitement !

Dernière modification par Zakhar (Le 15/09/2025, à 19:05)

Jarodd · Le 15/09/2025, à 20:36

Je pense que ma config n'est pas correcte
Je n'ai pas de .upload.1fichierfs sur mon poste (je le vois sur 1f.com). J'ai affiché les fichiers cachés.
Puis j'ai créé 2 répertoires (vides) dans /meda/..., ils n'apparaissent pas dans l'interface 1F.
Il faut que je cherche à tête reposée, là je vois pas ce qui cloche.

Zakhar · Le 15/09/2025, à 20:55

Ok !..

Déjà à mon sens ce n'est pas une bonne idée de monter un truc dans /media/jarodd, parce que c'est réservé par le système pour les périphériques amovibles du genre clé USB.
Le plus sensé est de monter dans ton home.
Personnellement, c'est directement monté comme ~/1fichier
Après si tu préfères, tu peux mettre dans ~/Documents/1fichier, ou à l'endroit que tu veux sous le /home/jarodd

Si ton montage n'a pas de répertoire .upload.1fichierfs, l'explication la plus probable est que tu n'aies jamais rien écrit sur le montage via 1fichierfs
Pour le vérifier, tu peux regarder sur ton interface web, à la rubrique "Gestion FTP". Si tu y vois un sous compte FTP qui s'appelle un truc du genre 1fichierfs-1234abcd, c'est que l'écriture a été déclenchée, mais je suppose que tu ne le verras pas plus !..
Donc, l'explication la plus simple pourquoi il n'y pas de fichier sur ton montage : tu n'y a jamais rien écrit !..

Après tu pourrais me donner ta ligne de commande de montage, car il y a effectivement des options qui interdisent l'écriture comme -ro (read-only, evidemment, un montage en lecture seule n'écrira pas, le kernel va bloquer), ou alors l'option --no-upload. Celle là, comme son nom l'indique, désactive complètement l'upload, donc l'écriture. La différence avec -ro c'est que ce n'est pas géré par le kernel, mais par mon driver, et donc des opérations considérées comme "écriture" par le kernel comme le fait de supprimer/renommer des fichiers/répertoires, faire des copies (lien) sont autorisées avec --no-upload, mais bloquées avant même d'arriver au driver avec -ro.

Une erreur classique possible aussi, c'est que l'utilitaire GUI-rsync que tu utilises tourne en root pour pouvoir répliquer les droits même quand les fichiers n'appartiennent pas à l'utilisateur. Or par défaut, un montage FUSE (ce n'est pas propre à 1fichierfs) n'est PAS accessible à root. C'est un cas unique sur Linux où l'utilisateur a plus de pouvoir que root. Bien sûr on peut faire en sorte que root ou d'autres puissent accéder à un montage fuse, mais il y a des choses à paramétrer pour cela, et des options à donner à 1fichiers : -o allow_other ou -o allow_root (ce sont des options "générique fuse" qui ne sont pas spécifiques à 1fichierfs, mais que celui-ci traite correctement).

Et j'insiste... faire la copie avec le gestionnaire de fichier est vraiment le plus simple, là tu ne peux guère te tromper... parce qu'en général on ne fait pas tourner le gestionnaire de fichier en root (ou alors on est vraiment tordu)

Dernière modification par Zakhar (Le 15/09/2025, à 21:02)

Jarodd · Le 16/09/2025, à 16:05

Bonjour,

Sur 1F.com > Gestion FTP, j'ai bien une ligne avec
- Nom d'utilisateur : 1fichierfs-xxx
- Dossier destination : .upload.1fichierfs

J'ai modifié le point de montage pour le mettre dans mon home.

J'utilise bien la copie avec nemo (ou cp en commande).

En retestant je viens de me rendre compte que la ligne ajoutée dans /etc/fstab génère une erreur si je la lance manuellement (je ne sais plus quels tests j'avais fait il y a plusieurs semaines, mais dans mon souvenir tout fonctionnait) :

$ 1fichierfs /home/jarodd/1fichier fuse _netdev,api-key=@/home/jarodd/.1fichier.key,ro,uid=1000,gid=1000,umask=0377,user,noauto 0 0
[1fichierfs     0.000] ERROR: Too many arguments: `fuse`

fuse est bien installé : "fuse est déjà la version la plus récente (2.9.9-8.1build1)".

La commande n'est pas avec la bonne syntaxe ? C'est "ro" le problème ? J'ai copié la commande dans le post #2 de cette discussion. L'erreur ne parle pas de cette option, donc je ne sais pas si elle est en cause.

Dernière modification par Jarodd (Le 16/09/2025, à 16:06)

Zakhar · Le 16/09/2025, à 18:12

Ta commande est bonne pour un /etc/fstab.

Mais si tu la lances en ligne de commande, il faut retirer ce qui ne sert qu'au /etc/fstab donc :
fuse
_netdev
user
noauto
et les deux zéro en fin de commande.

Aussi il faut précéder les arguments à partir de api-key d'un -o

D'ailleurs le message est clair, il te dit bien que l'argument "fuse" est en trop.
Si tu l'avais retiré, il aurait râlé sur la suite puisque tu n'as pas mis -o
Si tu avais mis -o, il aurait râlé sur _netdev puis les autres, puis les deux 0 0 à la fin !

Le "ro" n'est pas un problème, mais bien sûr ça veut dire que tu fais un montage "read-only" donc là tu ne pourras rien y écrire.

Ton but étant de tester l'écriture, il faut effectivement supprimer le ro de ta ligne de commande !

En résumé ça donne (j'ai laissé "ro" là) :

$ 1fichierfs /home/jarodd/1fichier -o api-key=@/home/jarodd/.1fichier.key,ro,uid=1000,gid=1000,umask=0377,log-level=6 -f
[1fichierfs     0.000] NOTICE: started: Tuesday 16 September 2025 at 19:08:01
[1fichierfs     0.000] INFO: successfuly parsed arguments.
[1fichierfs     0.000] INFO: log level is 6.
[1fichierfs     0.000] INFO: user_agent=1fichierfs/1.9.5
[1fichierfs     0.000] INFO: foreground.
[1fichierfs     0.000] INFO: <<< API(in) (iReq:1) folder/ls.cgi POST={"folder_id":0,"files":1} name=/
[1fichierfs     0.108] INFO: >>> API(out) (iReq:1) retry=0 json size=1114 hCode=200
[1fichierfs     0.108] INFO: <<< API(in) (iReq:2) folder/ls.cgi POST={"folder_id":1500xxxx,"files":1} name=.upload.1fichierfs
[1fichierfs     0.228] INFO: >>> API(out) (iReq:2) retry=0 json size=131 hCode=200
[1fichierfs     0.228] NOTICE: last shutdown was clean, nothing to resume.
[1fichierfs     0.228] INFO: adding options=-oro,fsname=1fichier.com,subtype=1fichierfs
[1fichierfs     0.228] NOTICE: Init done, starting fuse mount.
[1fichierfs     0.240] INFO: Asynchronous stream engine succesfully initialised with 4 threads, 64 streams, 131072 block size, 524288 max gap.
[1fichierfs     0.240] INFO: <<< API(in) (iReq:3) folder/ls.cgi POST={"folder_id":196xxxx,"files":1} name=.Trash-1000
[1fichierfs     0.568] INFO: >>> API(out) (iReq:3) retry=0 json size=366 hCode=200
[1fichierfs     0.572] INFO: <<< API(in) (iReq:4) folder/ls.cgi POST={"folder_id":196xxxx,"files":1} name=files
[1fichierfs     0.664] INFO: >>> API(out) (iReq:4) retry=0 json size=209 hCode=200
[1fichierfs     0.668] INFO: <<< API(in) (iReq:5) folder/ls.cgi POST={"folder_id":196xxxx,"files":1} name=info
[1fichierfs     0.784] INFO: >>> API(out) (iReq:5) retry=0 json size=441 hCode=200
[1fichierfs     0.788] INFO: https using curl sockets.
[1fichierfs     0.788] INFO: <<< API(in) (iReq:6) download/get_token.cgi POST={"url":"https://1fichier.com/?abcdfeghijklmon","single":1,"no_ssl":0} name=https://1fichier.com/?abcdfeghijklmon
[1fichierfs     1.120] INFO: >>> API(out) (iReq:6) retry=0 json size=60 hCode=200
^C[1fichierfs    31.332] NOTICE: Entering destroy.
[1fichierfs    31.336] INFO: Cleaning upon fuse unmount.
[1fichierfs    31.336] INFO: >> Refreshing on exit /=0x563fab2130a0.
[1fichierfs    31.336] INFO: Last memory status for leak check.
             Number Memory
Allocations:    691   952K
Frees      :    691   952K
Difference :      0      0
Contentions:      0      0

J'ai rajouté à la commande
log-level=6 pour qu'on voit un peu de chose
-f qui laisse le driver au premier plan dans le terminal, il ne passe pas en daemon. Quand tu as vu ce que tu voulais, il suffit de faire Ctrl-C et ça coupe le driver, comme tu le vois avec la ligne "NOTICE: entering destroy". Donc pas besoin de faire un fusermount -u /home/jarodd/1fichier, le CTRL-C s'occupe de tout et quand le driver rend la main, plus rien n'est monté.

Tu peux ainsi mettre le truc dans un terminal, laisser le terminal dans un coin, minimiser, et jouer avec ton montage, tu verras au fur et à mesure des messages dans ton terminal quand tu vas faire des choses qui sont du niveau "info" (entre autre tous les appels d'API).

Donc là, tout va bien on vérifie même qu'il n'y a pas de fuite mémoire, dans la ligne "Difference" on doit avoir 0 et 0 à la fin (autant de malloc que de free, et autant de quantité allouée que désallouée).

Si tu veux utiliser le niveau 6 de log quand tu auras trouvé les paramètres qui te conviennent, il vaut mieux rediriger les erreurs vers un fichier à part, sinon ça risque de polluer ta log système.
On fait ça avec log-file=/chemin/tonfichierlog.txt
Avec l'option -f on n'a pas besoin de ça puisque tout reste sur l'affichage du terminal et rien ne va polluer la log système.
L'option -f n'est pas possible dans le /etc/fstab où elle n'aurait pas trop de sens !

Le niveau 6 affiche jusqu'aux "info" (comme ci-dessus)
Le niveau 5 seulement jusqu'aux "notice"
Le niveau 4 est par défaut et affiche seulement ce qui est de "warning" (avertissement) ou plus grave. [Donc si on n'avait pas changé le niveau de log, on n'aurait vu aucun affichage ci-dessus, puisque aucun message n'est un "avertissement" !]
Niveau 3 correspond à "error"
Niveau 2 est "critique" : par exemple on n'a plus de mémoire, un appel système se plante, etc...
(Les niveaux 1 -alerte- et 0 -urgence-, ne sont pas utilisés par le programme).

Au démarrage (avant qu'il passe en daemon), le driver s'arrête dès qu'il y a une erreur, et donc ne fait pas le montage.
Une fois que le montage est fait, le driver ne s'arrête que s'il rencontre une erreur critique (erreur système grave).

Il existe un niveau 7 "debug", 1000 fois plus verbeux puisqu'il trace presque tous les appels de fonctions internes au code, mais il n'est pas disponible dans le package distribué sur le ppa, si tu as besoin du niveau 7, il faut compiler à partir du source.

Dernière modification par Zakhar (Le 18/09/2025, à 21:07)

Jarodd · Le 21/09/2025, à 19:23

Hello,

J'ai enfin eu un peu de temps pour tester

Ta commande fonctionne :

$ 1fichierfs /home/jarodd/Bureau/1fichier -o api-key=@/home/jarodd/.1fichier.key,uid=1000,gid=1000,umask=0377,log-level=6 -f

J'ai pas mal de notice et d'info lors du transfert, donc je laisse tourner. Si ça va bien jusqu'au bout, je tenterai avec fstab.

Par contre j'ai une question, tu m'as déconseillé d'utiliser /media/jarodd, car c'est réservé pour les appareils amovibles. Est-ce qu'il y a une limite "technique" ? Car dans mon souvenir il y a 5 ou 6 ans, j'utilisais aussi /media/jarodd/1fichier, et cela fonctionnait. Ce soir j'ai retesté par curiosité : les transferts dans ce répertoire ont été très rapides (quelques secondes pour plusieurs Go), alors que dans /home/jarodd/Bureau/1fichier, c'est même pas 1 Mbps (je suis en ethernet sur fibre 1Gbps). Mais je ne comprends pas cette différence (en mettant de côté l'usage "standard" des répertoires).

Sinon autre question : si je monte 1fichierfs dans mon /home, cela me prend bien de l'espace disque ? Ou c'est du virtuel ? Si je copie /home/jarodd/monfichierlocal dans /home/jarodd/Bureau/1fichier/monfichierlocal, j'ai bien 2 copies physiques du fichier ?
J'utilise aussi pCloud, qui se monte par défaut dans /home/jarodd/pCloudDrive/ mais c'est uniquement une copie de mon espace distant, qui ne prend rien sur mon disque en local.

Edit : je viens d'avoir un comportement étrange. La copie (via nemo GUI) a rencontré une erreur (répertoire indispo, je ne sais plus le libellé exact). Je suis remonté dans les logs, je n'ai pas vu autre chose que notice et info. Je ne sais pas si les transferts sont toujours actifs ou pas, vu que les logs tournent toujours mais que la fenêtre de copie s'est fermée. Est-ce possible que les logs soient décalés par rapport à la copie, et que les logs qui "tournent" encore soient simplement ceux des fichiers déjà copié quelques instants plus tôt ?
Je ne sais pas si je peux couper la commande : cela peut avoir un impact sur les transferts ou pas ?

Dernière modification par Jarodd (Le 21/09/2025, à 20:10)

Zakhar · Le 22/09/2025, à 08:10

Jarodd a écrit :

J'ai pas mal de notice et d'info lors du transfert, donc je laisse tourner. Si ça va bien jusqu'au bout, je tenterai avec fstab.

Normal, le niveau de verbosité étant 6, comme expliqué plus haut, au moins à chaque fois que le driver appelle une API tu as un message, plus d'autres détails !

Jarodd a écrit :

Par contre j'ai une question, tu m'as déconseillé d'utiliser /media/jarodd, car c'est réservé pour les appareils amovibles. Est-ce qu'il y a une limite "technique" ? Car dans mon souvenir il y a 5 ou 6 ans, j'utilisais aussi /media/jarodd/1fichier, et cela fonctionnait. Ce soir j'ai retesté par curiosité : les transferts dans ce répertoire ont été très rapides (quelques secondes pour plusieurs Go), alors que dans /home/jarodd/Bureau/1fichier, c'est même pas 1 Mbps (je suis en ethernet sur fibre 1Gbps). Mais je ne comprends pas cette différence (en mettant de côté l'usage "standard" des répertoires).

C'est principalement une question d'usage "standard", mais comme il y a aussi un traitement "spécial" de /media (snaps, udev, etc...) il vaut mieux éviter de tenter le diable et tomber dans des traitements parallèles qui foutent la grouille.
1Mbps (c'est à dire 120Ko/s) c'est effectivement poussivement lent, peut-être un effet de bord du bureau qui en plus est affiché, donc des programmes le relisent... Je tournais aux "bons moments" à ~40Mo/s à Paris et "seulement" à 20Mo/s (soit 160Mbps) à Nice. Les joies de l'internet.

Jarodd a écrit :

Sinon autre question : si je monte 1fichierfs dans mon /home, cela me prend bien de l'espace disque ? Ou c'est du virtuel ? Si je copie /home/jarodd/monfichierlocal dans /home/jarodd/Bureau/1fichier/monfichierlocal, j'ai bien 2 copies physiques du fichier ?
J'utilise aussi pCloud, qui se monte par défaut dans /home/jarodd/pCloudDrive/ mais c'est uniquement une copie de mon espace distant, qui ne prend rien sur mon disque en local.

C'est comme pCloud, ça prend absolument zéro espace local où que tu fasses ton montage. Que ce soit pour la lecture ou pour l'écriture, c'est absolument zéro (enfin si, il faut créer un répertoire pour monter, en ext4 ça doit prendre du genre 4K !).
D'ailleurs je fonctionne ainsi sur mon Raspberry Pi qui n'a qu'une carte SD de 32Go, il a donc "virtuellement" les 10To de mon stockage.
RClone qui est aussi un outil fuse supportant 1fichier.com, lui, fonctionne par défaut avec une "cache" locale dont tu paramètres la taille. Cela simplifie effectivement l'écriture qui passe d'abord par une copie dans la cache. Ce n'est pas du tout la direction que j'ai suivi avec 1fichierfs. Comme pCloud, tout se passe en ligne, et donc tu as absolument zéro espace consommé localement.
L'espace affiché par ton système pour le montage 1fichierfs est donc effectivement "virtuel" d'un point de vue de tes disques locaux, par contre l'espace est bien consommé sur ton quota disponible chez 1fichier.com (4To pour client premium).

Jarodd a écrit :

Edit : je viens d'avoir un comportement étrange. La copie (via nemo GUI) a rencontré une erreur (répertoire indispo, je ne sais plus le libellé exact). Je suis remonté dans les logs, je n'ai pas vu autre chose que notice et info. Je ne sais pas si les transferts sont toujours actifs ou pas, vu que les logs tournent toujours mais que la fenêtre de copie s'est fermée. Est-ce possible que les logs soient décalés par rapport à la copie, et que les logs qui "tournent" encore soient simplement ceux des fichiers déjà copié quelques instants plus tôt ?

C'est normal !
Lorsque les copies se sont terminées, vu de Nemo (ou ligne de commande), le "travail" côté serveur n'est pas encore terminé pour mettre tout dans ton stockage.
En effet, l'upload en ftp écrit dans un "spool", et régulièrement un "cron" se déclenche sur le serveur FTP pour récupérer les fichiers qui n'ont pas eu de modification dans les 5 dernières minutes et les poser sur le stockage.
Aussi, le fonctionnement de l'upload FTP avec le serveur 1fichier.com est d'envoyer tous les uploads vers un répertoire cible, en l'occurrence pour 1fichierfs, il s'agit de /.upload.1fichierfs.
Or lorsque tu copies, ce n'est pas là que tu veux tes fichiers, mais dans les répertoires où tu les as copiés.
Donc ce qu'il se passe un fois la copie "terminée" (de ton point de vue), c'est qu'au bout de 5 minutes 1fichierfs va forcer un "déclenchement FTP" (pour le cas où tu sois en "manuel") et ensuite il va "observer" le répertoire d'upload où les fichiers seront envoyés par 1fichier.com.
Chaque fois qu'il voit un fichier arriver dans ce répertoire, il le déplace à l'endroit où tu as voulu le copier dans le stockage distant.
Donc les messages que tu vois ce sont sans doute :
- des appels à l'API de listage, pour observer le répertoire .upload.1fichierfs (un toutes les 5 secondes)
- des appels à l'API de renommage lorsque les fichiers arrivent dans .upload.1fichierfs
- suivi d'un appel pour supprimer le "répertoire marqueur" dans .upload.1fichierfs
Bref c'est le "travail de fond" qui est encore nécessaire une fois que tu penses l'upload terminé !

Jarodd a écrit :

Je ne sais pas si je peux couper la commande : cela peut avoir un impact sur les transferts ou pas ?

Oui tu peux ! C'est le bénéfice d'avoir développer une fonction "reprise".
En fait tout ce "travail de fond" que tu vois se passer encore lorsque la phase de copie/upoad est terminée localement, eh bien il va se produire une fois que redémarrera le montage.
Cela aura un effet visible si, après avoir coupé le driver tu vas aller regarder la page web standard de 1fichier.com "Mes fichiers".
Tu ne verras pas les fichiers qui étaient dans leur cycle d'écriture au bon endroit, par contre tu vas observer que le répertoire .upload.1fichierfs va se remplir progressivement au fur et à mesure que le travail du serveur se produit suite à l'écriture de tes sauvegardes.

Lorsque tu relanceras le driver, il va faire son démarrage normal, puis il va aller tout de suite faire la "reprise" (des écritures dont le cycle a été interrompu).
Il va donc inspecter le répertoire .upload.1fichierfs, et s'il y trouve des fichiers qui étaient dans leur cycle d'écriture et que ce cycle est maintenant fini, il va "terminer le travail" en renommant déplaçant les fichiers au bon endroit de ton "cloud".

J'ai fait tout cela à dessein. Lorsque j'upload des fichiers qui font plusieurs 10aines de Go, ça peut prendre une bonne heure à écrire (à 20Mo/s) et ensuite ça va prendre plusieurs dizaines de minutes à compléter le cycle côté serveur. Parfois je n'ai pas le temps de rester derrière le PC au delà de la copie, donc je coupe, sachant que quand je vais revenir, plusieurs heures après, le cycle d'upload sera achevé avec la fonction de "reprise".

Voilà, en espérant que c'est clair !

Jarodd · Le 25/09/2025, à 13:06

Bonjour,
Merci pour les explications
Vu que ça fonctionne bien avec le montage manuel, je tente avec fstab, avec la commande du message #535 :

1fichierfs /home/jarodd/Bureau/1fichier fuse _netdev,api-key=@/home/jarodd/.1fichier.key,ro,uid=1000,gid=1000,umask=0377,user,noauto 0 0

J'édite le fichier avec vi. Mais 1fichierfs apparaît en rouge :

Je n'ose pas enregistrer, je ne sais pas ce que cela peut entraîner d'avoir un montage incorrect (pour les autres montages dans ce fichier).
Est-ce sûr ? C'est juste vi qui donne une fausse info, et la commande est correcte ?

Zakhar · Le 25/09/2025, à 17:04

Personnellement j'utilise nano dont la courbe d'apprentissage est moins forte que vi.
Je ne connais pas "l'intelligence" de vi et s'il fait des choses spéciales quand tu édites /etc/fstab.
Si c'est le cas, très évidemment, il ne connaît pas le type de montage 1fichierfs et c'est sans doute cela qu'il signale.

Ca ne peut absolument rien casser, d'autant que tu es en noauto, ce qui signifie que ton montage ne sera pas fait automatiquement au boot, donc rien à craindre sur le démarrage de ta machine !
Quand tu vas monter plus tard en tant que "user", c'est là seulement que la commande dans le /etc/fstab sera activée.

A priori tout est correct, sauf que là tu fais bien un montage read-only (l'option ro), c'est à dire que tu ne pourras que lire et pas écrire, supprimer, renommer/déplacer, etc... Si c'est bien ce que tu veux, c'est parfait !.. Si tu veux pouvoir aussi écrire, supprimer, renommer, etc... il faut retirer l'option ro.

Pour un montage dans le /etc/fstab, comme tu l'as spécifié, s'il y a un problème de commande incorrecte ou de montage, il faudra que tu ailles voir dans la log système. Si ça te convient, c'est parfait, sinon je suggère plutôt de rajouter un truc du genre : log-file=/tmp/1fichierfs-log.txt, ainsi les éventuels messages d'erreur et d'avertissement iront à cet endroit. Dans /tmp, c'est effacé à chaque redémarrage.

Dernière modification par Zakhar (Le 25/09/2025, à 17:09)

Jarodd · Le 27/09/2025, à 08:56

Bonjour,

Je viens de tenter l'ajout du fichier de log, mais le montage refuse de se faire :

[1fichierfs 0.000] ERROR: cannot open /tmp/1fichierfs-log.txt.

Le fstab contient :

1fichierfs /home/jarodd/Bureau/1fichier fuse _netdev,api-key=@/home/jarodd/.1fichier.key,uid=1000,gid=1000,umask=0377,user,auto,log-file=/tmp/1fichierfs-log.txt 0 0

Je l'ai donc enlevé, puis j'ai relancé le mount manuel :

$ sudo mount /home/jarodd/Bureau/1fichier
mount: (hint) your fstab has been modified, but systemd still uses
the old version; use 'systemctl daemon-reload' to reload.

Ayant eu récemment des problèmes causés par fuse, je me suis arrêté à cette étape, avant de faire une bêtise.

Edit : je ne comprends plus rien.
Dans nemo, le répertoire est devenu un binaire :

Et en commande :

27/09/2025 09:58:46 • jarodd@ubuntu:~
$ ll Bureau/1fichier 
ls: impossible d'accéder à 'Bureau/1fichier': Permission non accordée
27/09/2025 10:00:48 • jarodd@ubuntu:~
$ ll Bureau/
ls: impossible d'accéder à 'Bureau/1fichier': Permission non accordée
total 488
drwxr-xr-x  4 jarodd jarodd   4096 sept. 25 17:57  ./
drwxr-x--- 53 jarodd jarodd   4096 sept. 27 09:52  ../
d?????????  ? ?       ?            ?              ?  1fichier/

Je précise : j'ai réussi à faire un premier montage, et à faire des transferts. Puis j'ai eu des erreurs "I/O quelque chose", j'ai donc démonté avec umount, et quanfdj'ai voulu remonter, je n'ai pas vu, avec les erreurs indiquées dans ce message.

Edit : le périphérique était occupé après le umount, suppression impossible.
Je suis passé en sudo, pour refaire le umount, et supprimé le répertoire.
Puis avec mon user courant, j'ai recréé le dossier.
Le mount /home/jarodd/Bureau/1fichier l'a retransformé en binaire.
Un ls me remontre des permissions en ????????? (de même que l'user et le groupe).

Edit 2 : je pense avoir compris, il ne faut pas faire le montage avec sudo, puisque la ligne dans fstab précise "user" (donc montage sans root).
Sans sudo, le montage ne fait bien.
Par contre je ne retrouve que les répertoires de mes copies, pas les fichiers (j'ai plein de répertoires vides).

Dernière modification par Jarodd (Le 27/09/2025, à 10:55)

Zakhar · Le 27/09/2025, à 18:29

Haha, plusieurs choses, mais ça c'est du linux, pas propre à 1fichierfs.

Jarodd a écrit :

$ sudo mount /home/jarodd/Bureau/1fichier
mount: (hint) your fstab has been modified, but systemd still uses
the old version; use 'systemctl daemon-reload' to reload.

Le message est pourtant clair... la traduction en langue de Molière c'est que tu as modifié le fichier /etc/fstab mais tu n'a pas passé la commande indiquée (ou rebooté), et par conséquent le système (systemd en l'occurrence) continue d'utiliser le /etc/fstab d'avant la modification.

Donc lorsque tu modifies le /etc/fstab, il faut soit :
- rebooter (c'est long, mais c'est facile)
- exécuter : 'systemctl daemon-reload' comme indiqué.

L'autre problème c'est qu'en principe on ne monte pas un montage fuse en "sudo". Précisément, le fait d'avoir mis "user" dans le /etc/fstab sur le ligne de commande concernant un montage fuse (1fichierfs en l'occurrence), te permet de faire un "mount" sans le sudo.

Ta commande de montage devrait donc être :

$ mount /home/jarodd/Bureau/1fichier

Ensuite pour le /tmp/1fichierfs-log.txt inaccessible, c'est fort étrange.
La seule chose que je voie, c'est que tu aies créé ce fichier en "sudo", donc avec des droits root, et qu'ensuite tu essaye de monter en utilisateur normal. Assure-toi que le fichier en question est bien effacé avant, et tout devrait rouler.

Jarodd a écrit :

Edit 2 : je pense avoir compris, il ne faut pas faire le montage avec sudo, puisque la ligne dans fstab précise "user" (donc montage sans root).
Sans sudo, le montage ne fait bien.

Ah voila, donc tu avais trouvé !

Jarodd a écrit :

Par contre je ne retrouve que les répertoires de mes copies, pas les fichiers (j'ai plein de répertoires vides).

Ca c'est fort étrange, d'autant que tu as écrit plus haut que le programme continuait à écrire dans le terminal une fois les copies faites, preuve qu'il aurait dû tout à fait faire le travail.
Sans une "log" au moins au niveau 6 (tu peux l'envoyer en message privé), je ne vais guère pouvoir t'aider.
Tu peux aussi regarder sur l'interface standard de 1fichier.com si tu vois quelque chose, et également s'il y a des choses dans le répertoire .upload.1fichierfs

Dernière modification par Zakhar (Le 27/09/2025, à 18:36)

Jarodd · Le 27/09/2025, à 20:28

J'ai redémarré depuis ce message (rien à voir avec 1ffs). Le système a donc fait le mount au démarrage avec la ligne du fstab, donc si j'ai bien compris c'est l'équivalent d'un sudo ?
Pourtant le répertoire 1fichier reste inaccessible (permissions ?????????). Un chmod 777 (c'est pour tester) ne change pas les permissions.
Je n'ai pas fait de commande mount manuelle, tout vient du montage auto.
Pour les logs, /tmp appartient à root, je ne sais pas si user a le droit d'y écrire ou juste de lire ?

Zakhar · Le 27/09/2025, à 23:42

Le système ne fait pas le mount au démarrage avec l'option noauto dans /etc/fstab. C'est sans doute toi qui l'a fait, créant un fichier 1fichierfs-log.txt appartenant à root.
Ensuite quand tu montes normalement en user, le montage ne peut pas se faire parce que 1fichierfs ne peut plus écrire sur /tmp/1fichierfs-log.txt qui appartient à root.

/tmp appartient toujours à root, mais il a des droits spéciaux, observe le "t" sur "other" (les 3 derniers), sinon on ne pourrait pas écrire dedans :

drwxrwxrwt  22 root root   540 sept. 28 00:35 tmp/

Essayer de changer les droits de la racine d'un montage fuse ne fonctionne pas. Tu peux changer les droits avant de monter, 1fichierfs va propager les mêmes droits sur toute l'arborescence.
Comme 1fichier.com (le serveur) n'a pas la notion des droits Posix, faire un chod à l'intérieur du montage répondra OK mais ne fera absolument rien. J'ai demandé une évolution à 1fichier.com pour cela, mais pas sûr qu'ils aient envie de la coder !..

Si tu as ???? sur la racine du montage c'est que tu fais un truc de travers forcément, puisque tu y es arrivé en ligne de commande.

Commence toujours du plus simple : la ligne de commande, avec le moins d'options possibles, puis tu rajoutes les options qui t'intéressent une à une, et enfin tu transposes dans /etc/fstab

Dernière modification par Zakhar (Le 27/09/2025, à 23:45)

Jarodd · Le 30/09/2025, à 11:09

Bonjour,

Je dois vraiment être mauvais, car je ne comprends pas ce qui se passe.

J'ai refais le montage manuel. Le dossier a les bonnes permissions. Les transferts se passent bien, ça a tourné pendant plus de 24h sans problème.
Ça a tourné tout seul pendant la nuit. Le matin, je constate que les transferts sont finis. Dans nemo j'ouvre le répertoire, et là j'ai cette erreur :
"Erreur lors de l'obtention des informations du fichier /home/jaroddBureau/1fichier
Noeud final de transport pas connecté - Sélectionnez un autre visionneur et essayez à nouveau"

Je me dis que le montage a peut-être expiré, après une certaine période sans activité. Je coupe la commande (où les logs ne bougent plus), je relance la commande pour refaire le montage, et j'ai l'équivalent :

[1fichierfs     0.000] ERROR: getting stats of `/home/jarodd/Bureau/1fichier`: Transport endpoint is not connected

Je vérifie les permissions avec un ls : c'est le retour des ????????

J'ai probablement refait "un truc de travers", mais je ne sais pas quoi.

La bonne nouvelle c'est que sur l'interface 1F, je vois bien les fichiers.
La mauvaise, c'est que le compte n'y est pas : j'ai transféré 665 Go, et l'interface me dit que .upload.1fichierfs fait 1,18 To.
Comme ce sont des fichiers chiffrés, je ne sais pas lequels sont manquants.

Edit : suite à ce problème, j'avais le ventilo qui soufflait un peu, beaucoup, aléatoirement.
Apparemment c'est causé par gjs, un programme qui scrutait le montage en échec (car erreur "transport endpoint...").

J'ai donc fait ceci :
$ pkill -f 1fichierfs
$ fusermount -u ~/Bureau/1fichier
$ rmdir ~/Bureau/1fichier

Puis redémarré gjs :
$ gnome-extensions disable ding@rastersoft.com (puis enable)

Le processus à 30% du CPU a disparu.

D'après Mistral, il est déconseillé de faire un montage sur le bureau, car DING surveille ce répertoire. Il conseille directement ~/ (ou un sous-répertoire du home).

Dernière modification par Jarodd (Le 30/09/2025, à 16:26)

Zakhar · Le 30/09/2025, à 21:19

Il est tout à fait possible que tu sois tombé sur un bug du programme... il doit bien encore y en avoir quelques uns !

Le montage n'expire pas "après inactivité" !..
Tiens d'ailleurs regarde les stats de mon Raspberry Pi :

$  cat ~/1fichier/.stats 
Uptime: 90d 01:21:45

Readers:
    Files    Streams  Start streams             Fuse requests
   Cur/Tot.  Cur/Tot. AvgTim MaxTim Down. N.Req AvgTim MaxTim Speed Av.Sp Over.
01: 0   178   0   351 .24933 1.8362 5649M 58238 .00213 2.6489     0 7599K 49.9M
02: 0   386   0  2699 .11472 2.0097  534G 4946K .00145 3.7133     0 8718K 2685M
03: 0   128   0   291 .23907 1.2379 12.9G  182K .00143 .43106     0 8179K  333M
-------------------------------------------------------------------------------
Tt  0   692   0  3341 .13970 2.0097  552G 5185K .00146 3.7133     0 8693K 3069M

API:
                        N.Req  Avg Time  Max Time Retry N.Err
folder/ls.cgi         :  1209    0.2187    1.1330     0     0
download/get_token.cgi:   550    0.1889    1.0272     0     1
user/info.cgi         :     8    0.2083    0.2812     0     1
file/mv.cgi           :     2    0.1672    0.1679     0     0
file/chattr.cgi       :     2    0.1689    0.1698     0     0
file/rm.cgi           :    43    0.2271    0.9180     0     0
folder/rm.cgi         :     1    0.2085    0.2085     0     0
ftp/users/ls.cgi      :     1    0.3080    0.3080     0     0
fallback/get_token    :    40    0.3749    0.4599     0     0
--------------------------------------------------------------
Total                 :  1856    0.2133    1.1330     0     2

         Trig. Timer Poll. Write   API Error  Auto   Total
Refresh:     0   245     1     0     7     0     0     253

Comme tu vois, ça fait 90 jours que 1fichierfs tourne sans aucun problème [et en plus en mode "DEBUG"] !
Sur ces 90 jours, j'ai téléchargé 552Go (je ne fais pas d'upload avec la Pi... bien trop lent !)
Autant te dire qu'il y a bien des larges périodes d'inactivité, parce 1/2To en 3 mois, c'est pas fulgurant, même si la vitesse moyenne en téléchargement actif est 8693K, ce qui est pas mal pour le Pi.

Donc oui, depuis le début je conseille ~/1fichier, c'est à dire directement dans ton ~/ home (soit /home/jarodd et donc : /home/jarodd/1fichier), si possible éviter un répertoire qui est potentiellement squatté par d'autres outils comme /media ou /home/bureau.

Le ???? est donc normal si ça a planté et le message "Transport endpoint is not connected" est typique d'un driver fuse qui a planté.

Tu peux toujours utiliser l'option -o auto_unmount pour que le démontage soit automatique si le driver plante... mais ça ne corrige pas le plantage !

Donc désolé... tu es bel et bien tombé sur un plantage...

Pour aider, il me faut au moins une log (journal) du niveau 6. Donc tu envoies ça vers un fichier (options : --log-level=6 --log-file=/chemin/fichier_de_ton_choix.txt), et si ça plante tu récupères le fichier et tu me l'envoie en message privé. Je te dirai alors si le niveau 6 est suffisant ou s'il me faut du niveau 7... qui est vraiment très verbeux et nécessite une "compilation manuelle".

Pour tes fichiers dans .upload.1fichierfs, s'il restent là après un redémarrage du programme, ce sont effectivement des scories de plantage. Tu peux les enlever.

Comme le conseille 1fichier.com, il est une bonne pratique qui consiste à vérifier si ce que tu as uploadé est bien correct et identique à tes fichiers locaux. Pour cela un "diff" sur les fichiers uploadés te le diras (diff -s pour avoir le message "fichier identique", sinon diff ne montre que les différences et il est silencieux s'il n'y a pas de différences !)

P.S.: en 24.04 j'ai effectivement constaté un bug sur la partie écriture qui est pourtant fort ancienne. En réalité j'écris toujours en chiffré via encfs, et le bug semble envoyer des blocs de zéros.. mais cela à encfs parce que sinon celui-ci aurait râlé en relisant les fichiers. Le bug ne tombe donc pas sur 1fichierfs... mais peut-être ce serait le cas si je ne passais pas par encfs d'abord !..
Est-ce que c'est un effet de bord de drivers fuse qui sont en fuse 2 alors que par défaut on a du fuse 3 sur la 24.04 ? En tout cas je soupçonne un bug kernel ou lib_fuse... c'est pas cool de balancer des zéros au milieu des blocs d'écriture !..
Je n'ai pas encore recherché davantage parce que j'ai laissé tomber la 24.04 et je reste en 20.04. Il y a trop de bugs persistants en 24.04 malgré ses presque 2 ans... et ce sur plein de logiciels. Certains sont bien sûr dus à ma configuration graphique avec deux écrans dont un en fractionnaire, mais ça reste du bug que je n'ai pas en 20.04 (car je m'y suis résolu de ne pas utiliser le fractionnaire aussi !).
Mais bon, c'est peut-être autre chose... et un fichier "log" reste nécessaire pour que j'aie éventuellement une idée du bug

Dernière modification par Zakhar (Le 30/09/2025, à 22:12)

Zakhar · Le 01/10/2025, à 10:53

[Annonce]
Je vais profiter des quelques jours nuageux qui s'annoncent pour publier la dernière version qui tourne sans faille sur mes PC depuis plusieurs mois et implémente le "encfs-rename-friendly".
A part quelques améliorations sur la spécification des chemins dans les paramètres, cette version ne vous apportera pas grand chose si vous n'utilisez pas encfs, mais cela me permet de "cranter" pour passer à la suite.

[Fonctionnalités à venir]
(voir le /TODO sur le gitlab)

Adaptations pour les utilisateurs "inscrits" : depuis quelque temps, l'API est ouvertes aux "inscrits" (ou non-clients puisqu'ils ne payent pas). La grosse limitation est que la lecture n'est pas possible : il faut passer par le site web car c'est financé par la pub pour ces "non-clients" (ou clients non-payant). Cependant tout le reste, y compris l'écriture est possible. A ce jour le driver ne fait pas la distinction, et tenter de télécharger quand on est inscrit peut provoquer des accès refusés (403) et conduire au bannissement temporaire si on insiste !
Utilisation du compte FTP principal (au lieu d'un sous-compte) pour l'écriture. Cette fonction est plutôt orientée pour les "inscrits" vu qu'une des limitations est qu'ils n'ont précisément pas de sous-compte, par conséquent la façon actuelle d'écrire ne fonctionne pas pour eux. Le gros inconvénient de cette méthode est que le compte FTP principal utilise le mot de passe du compte, ce qui oblige l'utilisateur à le révéler à 1fichierfs tandis que pour l'instant on ne donne "que" la clé d'API -ce qui doit tout de même représenter 95% des choses possibles en l'occurrence !-. J'ai fait une demande d'évolution à 1fichier.com pour qu'ils autorisent le changement du mot de passe pour le compte FTP principal, ce qui n'est pas possible aujourd'hui, qu'on soit inscrit ou Premium (mais les Premium peuvent utiliser les sous-comptes FTP pour cela). Donc bien sûr pour les Premium, pour des raisons de sécurité, il vaudra mieux s'abstenir d'utiliser cette fonctionnalité, à moins qu'on trouve très gênant de voir 1fichierfs utiliser un sous-compte FTP !.. Si 1fichier.com implémente la possibilité de mettre un mot de passe FTP-principal différent du mot de passe du compte... à ce moment là la fonctionnalité sera meilleure.
Coller-pour-copier. La fonction "copier" de l'API est actuellement utilisée pour les copies "internes", c'est à dire quand on fait l'équivalent d'un lien "dur" (ln). Elle fonctionne cependant avec tout lien qui n'est pas restreint. Ainsi l'idée, pour un lien de "partage" est de transformer en une copie le collage d'un tel lien vers un fichier virtuel donné. Associé à un script pour Nautilus/Nemo/Dolphin, cela vous permettra de prendre un lien de partage et avec un copier/coller d'en faire une copie vers le répertoire de votre choix via votre gestionnaire de fichier favori... ou en ligne de commande :
```
echo "https://1fichierfs.com/?12324567abcdef&af=345" >>~/1fichier/chemin/.incoming.txt
```
Le résultat de la commande (ou script déclenché via Nautilus) est de copier le fichier dont le lien est donné dans le répertoire visé + d'enrichir le fichier virtuel ".incoming.txt" dans ce répertoire d'un rapport de succès/échec de la copie. Cela vous évite donc d'avoir à passer par l'interface web pour copier des liens externes de partage vers votre stockage, et surtout le choix du répertoire cible est plus facile via votre gestionnaire de fichier.
Autoriser la reprise (append) d'une écriture. Le cas d'usage principal vise à couvrir le comportement de firefox -ou autre navigateur- lors d'un téléchargement. En effet le navigateur va régulièrement faire flush/close puis continuer à écrire dans le fichier téléchargé en "append". Comme l'append (reprise d'écriture) n'est actuellement pas implémenté - bien que possible pour 1fichier.com-, tenter de télécharger avec Firefox directement vers votre cloud 1fichier.com va sans doute échouer (sauf éventuellement pour de très petits fichiers). Donc actuellement, il faut commencer par télécharger localement avant de copier vers votre "cloud" 1fichier.com

Il y a aussi d'autres urgences de nettoyage de code, deprecations, travaux divers, mais comme elle n'offrent pas de nouvelles fonctionnalités majeures, je vous laisse voir le /todo si vous en êtes curieux !

Dernière modification par Zakhar (Le 01/10/2025, à 11:09)

Jarodd · Le 04/10/2025, à 20:31

Bonjour,
J'ai fit une pense-bête pour utiliser systemd au lieu de fstab. Le voici (copier coller du format markdown) :

# Monter 1fichier.com automatiquement sous Linux (Ubuntu 24.04+)

Ce guide permet de monter votre compte **1fichier.com** comme un dossier local (`~/1fichier`) grâce à `1fichierfs`, avec un **démarrage automatique à chaque connexion**.

> ✅ Fonctionne sous **GNOME + Wayland** (Ubuntu 24.04 par défaut)  
> ✅ Aucune interaction avec le bureau ou les extensions  
> ✅ Montage stable, géré par `systemd`

## ? 1. Obtenir une clé API

1. Allez sur [https://1fichier.com/console/params.pl](https://1fichier.com/console/params.pl)
2. Copiez votre **Clé API** (section « Clé API »)
3. Enregistrez-la dans un fichier sécurisé :

```bash
echo "MA_CLE_API" > ~/.1fichier.key
chmod 600 ~/.1fichier.key
```

## 2. Installer 1fichierfs

1. sudo add-apt-repository ppa:alainb06/astreamfs
2. sudo apt update
3. sudo apt install 1fichierfs

Ou 

```
pip3 install --user 1fichierfs
```

## ? 3. Nettoyer les résidus éventuels

```
pkill -f 1fichierfs 2>/dev/null
umount ~/1fichier 2>/dev/null || fusermount -u ~/1fichier 2>/dev/null
rm -rf ~/1fichier
mkdir ~/1fichier
```

## ▶️ 4. Tester manuellement 

1fichierfs -f ~/1fichier --api-key "$(cat ~/.1fichier.key)"

Le terminal reste bloqué, c'est normal.

Dans un autre terminal :

```
ls ~/1fichier
```

Appuyez sur Ctrl + C pour arrêter le premier terminal.

## ? 5. Créer le script de lancement 

```
mkdir -p ~/.local/bin
cat > ~/.local/bin/mount-1fichier.sh << 'EOF'
#!/bin/sh
exec 1fichierfs -f "$HOME/1fichier" --api-key "$(cat "$HOME/.1fichier.key")"
EOF
chmod +x ~/.local/bin/mount-1fichier.sh
```

## ⚙️ 6. Créer le service systemd 

```
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/1fichier.service << EOF
[Unit]
Description=Montage 1fichier.com
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/home/$USER/.local/bin/mount-1fichier.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target
EOF
```

## ? 7. Activer le service 

```
systemctl --user daemon-reload
systemctl --user enable --now 1fichier.service
```

## ✅ 8. Vérifier le service

```
systemctl --user status 1fichier.service
ls ~/1fichier
```

## ?️ Commandes utiles 

```
# Voir l'état
systemctl --user status 1fichier.service

# Redémarrer
systemctl --user restart 1fichier.service

# Arrêter
systemctl --user stop 1fichier.service

# Désactiver au démarrage
systemctl --user disable 1fichier.service
```

## ? Désinstaller complètement 

```
systemctl --user disable --now 1fichier.service
rm -f ~/.config/systemd/user/1fichier.service
rm -f ~/.local/bin/mount-1fichier.sh
rm -f ~/.1fichier.key
rm -rf ~/1fichier
systemctl --user daemon-reload
```

Zakhar · Le 05/10/2025, à 08:35

Jarodd a écrit :

Bonjour, ...

C'est cool de partager ses développements !

Si je peux me permettre quelques petites remarques :

# Monter 1fichier.com automatiquement sous Linux (Ubuntu 24.04+)

Ce guide permet de monter votre compte **1fichier.com** comme un dossier local (`~/1fichier`) grâce à `1fichierfs`, avec un **démarrage automatique à chaque connexion**.

> ✅ Fonctionne sous **GNOME + Wayland** (Ubuntu 24.04 par défaut)

1fichierfs n'ayant pas d'interface graphique, effectivement, comme tu le dis : pas d'interaction avec le bureau (ou tout élément graphique) puisque c'est juste un "daemon".
Les deux dépendances du programme sont curl et FUSE que l'on trouve à peu près partout (bien qu'il soit possible de compiler le kernel sans support FUSE).
Sur le ppa, les versions supportées pour Ubuntu (uniquement les LTS) vont de 16.04 à 24.04
Je vais sans doute prochainement déprécier les 16.04 et 18.04 qui m'obligent à garder une ancienne installation de 16.04, et pour la 16.04, on a une particularité dans le "make" car elle utilise gnutls au lieu de openssl (obscure raisons de parallélisme).

Je mets aussi des .deb des versions Raspberry Pi que j'utilise, actuellement Bookworm 64 bits.

Pour les autres distrib, il "suffit" de recompiler à partir du source. Du moment qu'on trouve les deux librairies dépendantes, c'est juste une commande à lancer. Certains "clients" ici utilisent d'ailleurs 1fichierfs sur Arch.

Après, le commentaire explique sans doute que tes instructions peuvent ne pas fonctionner sur d'autres distrib. Effectivement en 16.04 on n'avait pas systemd qui a d'ailleurs était très décrié. Le process de démarrage était une adaptation de l'init System V améliorée par Canonical.

## ? 3. Nettoyer les résidus éventuels

```
rm -rf ~/1fichier
```

Ça c'est dangereux et à ne pas recommander pour tous les cas de figure !
En effet, malgré la ligne précédente qui tente de démonter, il peut y avoir des cas où le démontage échoue (fichier en occupation), et on risque alors de lancer une commande qui va détruire tout le stockage distant ! Par exemple, si tu as un ISO d'Ubuntu dans ton stockage et que tu l'as monté, même sans accès actif au moment du démontage, le kernel va refuser le démontage car il y a des ressources occupées (l'ISO monté). Dans ce cas les deux démontages que tu as prévus échouent, le montage reste actif, et ça enchaîne sur la destruction de tout le stockage distant... super dangereux donc !..
Aussi, on peut parfaitement monter par dessus une arborescence qui contient déjà des fichiers locaux (ou un autre montage). Par défaut une telle manœuvre va échouer, mais il existe précisément le commutateur standard FUSE :

    -o nonempty            allow mounts over non-empty file/dir

pour permettre, comme son nom l'indique, un montage vers un endroit non vide. Bien sûr une fois le montage ainsi forcé, les fichiers qui existaient précédemment dans l’arborescence sont masqués.
Donc faire un "rm -rf " après démontage pourrait détruire tout un tas de données qui sont là et que l'utilisateur veut garder !

Aussi, un faute de frappe étant vite arrivée (si on tape au lieu de faire copier/coller), si l'utilisateur insère une espace entre le ~ et /1fichier ... je te laisse imaginer la catastrophe nucléaire !

Suggestion : juste mettre un commentaire pour expliquer que l'utilisateur peut, au besoin, supprimer les fichiers dans ~/1fichier après vérification que le démontage s'est bien passé, et supprimer ce répertoire s'il n'en a plus besoin.

## ▶️ 4. Tester manuellement 

1fichierfs -f ~/1fichier --api-key "$(cat ~/.1fichier.key)"

Oui, cela fonctionne bien sûr, mais pour des raisons de sécurité je ne le conseille pas.
En effet, "$(cat ~/.1fichier.key)" va afficher le contenu du fichier, donc la clé d'API et c'est comme si on avait mis la ligne de commande :

1fichierfs -f ~/1fichier --api-key Ma_Cle_API_en_clair

En soit, pour l'utilisateur en session, c'est OK, puisqu'il connaît sa propre clé d'API. Seulement cela va s'afficher aussi en clair dans la liste des process si on fait par exemple :

ps -ef | grep 1fichier

Donc si un autre utilisateur (ou virus espion) est "branché", même sans droits root, sur la même machine, il verra la clé en clair dans la liste des process.

Pour éviter cela, et aussi éviter une commande avec une commande cat imbriquée, la bonne façon de spécifier une clé d'API qui se trouve dans un fichier est de spécifier :

1fichierfs -f ~/1fichier --api-key=@~/.1fichier.key

Le fait de commencer la chaîne après --api-key par un @ indique à 1fichierfs qu'il ne s'agit pas directement de la clé d'API mais d'un fichier qui contient celle-ci.
Comme tu as très justement restreint les droits sur ce fichier au seul utilisateur, notre "espion" peut continuer à voir la ligne de commande et le fichier en question, mais il ne peut pas afficher son contenu (à moins qu'il soit root, mais là c'est game over !), donc pas d'accès à la clé d'API en clair.

Rien de tel d'ailleurs que le "man" (manuel) que je t'encourage à lire, il explique tout cela (et en français, contrairement au --help qui n'est qu'en anglais) :

$ man 1fichierfs
...
       --api-key=CléAPI
              La Clé API du compte 1fichier.com.
              Cette méthode la plus simple pour spécifier la Clé API a un inconvénient : la Clé API sera visible en clair via la commande ps.
              Si c'est un problème de sécurité dans la configuration où c'est utilisé, voir une des méthodes alternatives ci-dessous.

              Si la Clé API commence par @, c'est interprété comme le nom d'un fichier (après retrait du @ initial) qui contient la Clé API.
              Avec cette méthode, la Clé API n'est plus visible par la commande ps, mais elle est en clair dans le fichier spécifié. La sécurité peut encore être raffinée avec la méthode suivante.

              @ tout seul signifie l'entrée standard : stdin.
              Cela permet, par exemple, d'utiliser un "pipe" avec un autre programme qui déchiffrerait la Clé API.

              En dernier ressort, si cette option n'est pas présente, la Clé API sera demandée à l'utilisateur.

...

On peut sans doute sécuriser de meilleure façon, par exemple comme je le fais avec encfs, la clé permettant d'ouvrir le montage est stockée dans le "keyring" Gnome et nécessite que la session soit déverrouillée (mon PC de bureau démarre la session sans mot de passe).
Sur encfs on spécifie ça ainsi :

--extpass="secret-tool lookup encfs passwd"

Je n'ai pas testé, mais on peut sans doute de même mettre la clé d'API dans le "keyring" et par une redirection (pipe) récupérer cette chaine depuis le keyring sécurisé Gnome. Ainsi la clé n'est même plus dans un fichier lisible en clair !

Mais bon, c'est un raffinement, ton code fonctionne aussi bien sûr !

## ⚙️ 6. Créer le service systemd 

```
mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/1fichier.service << EOF
[Unit]
Description=Montage 1fichier.com
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/home/$USER/.local/bin/mount-1fichier.sh
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target
EOF
```

## ? 7. Activer le service 

```
systemctl --user daemon-reload
systemctl --user enable --now 1fichier.service
```

Ah c'est cool ça... je viens d'apprendre un truc, merci !

systemctl --user

C'est pour lancer des commandes, je présume, au démarrage de la session, d'une manière standard qui ne dépendent pas du fait qu'on soit sous Gnome, KDE ou autre !
En effet, dans le boot de la machine, ça ne fonctionnerait pas, à moins de faire le montage en root ce qui reste possible mais n'est guère recommandé !

Spécifier

After=network-online.target

... est parfaitement prudent ! En réalité la session démarre sans même cette target atteinte pour donner une impression de rapidité, et c'est très réussi.
Aussi, depuis pas mal de temps, 1fichierfs va "attendre" au démarrage que le network soit là. Par défaut il attend 60 secondes, mais on peut bien sûr changer le paramètre avec :

$ 1fichierfs --help
...
    --network-wait=seconds
                      Default: 60 (1 minute).
                      How long to wait for network to become ready when
                      1fichierfs starts.

...

Spécifier après la target "network" est bien sûr plus propre. C'est parfait !
L'effet sera un peu différent de l'attente programmée dans 1fichierfs. Prenons le cas d'un PC portable connecté uniquement en Wifi, avec le système que tu proposes, systemd va attendre indéfiniment que l'utilisateur veuille bien brancher la Wifi. On pourrait avoir l'impression qu'il ne se passe rien et que la commande a échoué.
En utilisant le timing de 1fichierfs, au bout d'une minute le programme va échouer et indiquer la raison qu'on retrouvera dans le journal de systemd.

Les deux fonctionnements sont donc possibles et avec des comportements différents selon ce que l'on souhaite !

[Edit] je pense qu'en fait les 2 mécanismes vont fonctionner en parallèle. En effet, sans doute que systemd considère qu'une fois qu'il a lancé, par exemple, wpa_supplicant, la pile Wifi est lancée et donc network target est atteint. C'est le cas d'un point de vue pile logicielle, mais ensuite il y a toute la connexion Wifi avec les paramètres d'utilisateur qui peut prendre du temps. Dans le cas cité ci-dessus, systemd va sans doute lancer 1fichierfs sans attendre que la Wifi soit vraiment opérationnelle. Et là, le mécanisme codé dans 1fichierfs prendra le relais et attendra le temps nécessaire dans la durée maximale spécifiée. A tester pour observer le comportement !

## ? Désinstaller complètement 

```
systemctl --user disable --now 1fichier.service
rm -f ~/.config/systemd/user/1fichier.service
rm -f ~/.local/bin/mount-1fichier.sh
rm -f ~/.1fichier.key
rm -rf ~/1fichier
systemctl --user daemon-reload
```

Il doit y manquer les commandes pour désinstaller 1fichierfs si on n'en veut plus (sudo apt remove) et retirer le ppa (je ne l'ai plus en tête).
Et même remarque sur le dangereux rm -rf !

En tout cas, bravo pour les suggestions et les idées.

Question : des nouvelles du plantage que tu avais constaté sur l'écriture ?

Dernière modification par Zakhar (Le 05/10/2025, à 10:57)

Jarodd · Le 22/10/2025, à 17:11

Bonjour,
Merci pour les remarques sur la doc

Zakhar a écrit :

Question : des nouvelles du plantage que tu avais constaté sur l'écriture ?

Aujourd'hui, j'ai passé le journée à envoyer du contenu (~600 Go). Et de nouveau rien n'apparaît dans l'interface 1F. C'est juste un constat, je n'ai rien analysé pour l'instant.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#526 Le 13/09/2025, à 22:29

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#527 Le 14/09/2025, à 10:28

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#528 Le 14/09/2025, à 18:15

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#529 Le 14/09/2025, à 19:06

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#530 Le 14/09/2025, à 19:10

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#531 Le 15/09/2025, à 11:41

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#532 Le 15/09/2025, à 19:00

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#533 Le 15/09/2025, à 20:36

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#534 Le 15/09/2025, à 20:55

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#535 Le 16/09/2025, à 16:05

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#536 Le 16/09/2025, à 18:12

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#537 Le 21/09/2025, à 19:23

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#538 Le 22/09/2025, à 08:10

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#539 Le 25/09/2025, à 13:06

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#540 Le 25/09/2025, à 17:04

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#541 Le 27/09/2025, à 08:56

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#542 Le 27/09/2025, à 18:29

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#543 Le 27/09/2025, à 20:28

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#544 Le 27/09/2025, à 23:42

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#545 Le 30/09/2025, à 11:09

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#546 Le 30/09/2025, à 21:19

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#547 Le 01/10/2025, à 10:53

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#548 Le 04/10/2025, à 20:31

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#549 Le 05/10/2025, à 08:35

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

#550 Le 22/10/2025, à 17:11

Re : [1fichier] "Montez" votre stockage 1fichier en une commande simple !

Pied de page des forums