Tous les projets

Bonjour,

Il est désormais impossible de monter le disque de la Freebox via SMB/CIFS.

La précédente commande utilisée est :
mount -t cifs //fqdn_ou_IP_serveur_FTP/dossier /dossier/où/monter/le/dossier/SMB

Celle-ci ne fonctionne plus ...

Merci de votre aide.

Hello,

Alors je résume la chose.

Install fraiche d’une VM (peu importe la distrib le problème est exactement le même à chaque fois) debian avec accès aux disques de la Freebox (activation du smbv2 nécessaire).

premier démarrage de la VM ⇒ freeze (à n’importe quel moment car j’ai look la console au boot et c’est pas à une étape particulière qu’elle plante). Impossible de l’éteindre ou de forcer l’arrêt. Si j’attends que ca se passe c’est toute la freebox qui ne répond plus avec les CPU qui grimpent en flèche niveau température…Obliger de débrancher / rebrancher la delta et d’aller rapidement dans les VM pour forcer l’arrêt (qui fonctionne cette fois)et supprimer la VM.

Nouvelle install fraiche d’une VM debian, sans accès aux disques Freebox (donc smbv2 off) et tout roule…

Bonjour, étant novice sur Plex et encor plus sur les VM… J’ai donc crée une VM en suivant un tuto sur internet, au début je n’arrivais pas à autoriser l’accès au disque de ma freebox pour la VM j’ai donc du activer le SMBv2. Une fois activer j’ai pu en effet cocher la case donné l’accès aux disque à ma VM, j’ai donc suivit la procédure afin d’installer Plex, tout s’est bien déroulé et j’avais accès à mon Plex… Mais les films/série n’était pas disponible je n’arrivais pas à les lire me disant qu’ils étaient indisponible.
J’ai donc chercher un peu sur internet j’ai cru comprendre cela venait d’un soucis de SMBv1 ou v2 mais je n’en pas su résoudre mon soucis… J’ai donc tout recommencer depuis le début en effaçant ma VM et en la recréant mais maintenant j’ai directement un soucis dans la console me disant qu’il n’arrive pas à monter les disques. (photo ci-joint) https://gyazo.com/8b0823a41db8ca247100bd7b3aaf936c

D’où peut provenir ce soucis ? D’avance merci. Cordialement,
Pimpus

Bonjour,

Contexte :

Client win10pro 1903
Server Delta 4.1.1 - 3h d’uptime
Disque source Toshiba P300
Transfert LAN (lien Gigabit)
Disque cible1 : array 3x1To RAID0 disques HGST 7K1000-1000 - logements 2,3,4 (volume “perso”)
Disque cible2 : ssd 512Go - logement 1 (disque “fonctionnement box”)
Share windows activé avec authentification (login “freebox” par défaut + mdp ponctuel)
VM arrêtée en cours de transfert, sans effet.

Share 1 et 2 montés via net use

ServerName ShareName UserName     Credential     Dialect NumOpens
---------- --------- --------     ----------     ------- --------
fbxsrv     3To       saloon\abc fbxsrv\freebox 1.5     1
fbxsrv     ssd512    saloon\abc fbxsrv\freebox 1.5     1

Constat :

Lancement du transfert source vers cible1 via robocopy (source cible /MIR /R:0 /W:0 /NP)
⇒ Qu’importe la taille et le type du fichier (jpeg ~4Mo, raw ~25Mo, mp4 ~500Mo), le transfert occile de 0 (!) à 100Mbit/s (task manager) avec parfois une pointe à 500.
Le transfert peut très bien s’interrompre en plein milieu d’un fichier pour reprendre ensuite comme si de rien n’était.
Au bout de 2h de copie ⇒ ~55Go transférés.

Avant que je n’interrompe le massacre, j’ai lancé un test de copie (copy/paste windows) d’un iso win10 vers le ssd (cible2). Même combat : plafond à 10Mo/s, instable.
La source n’était pas la même (ssd système du pc, sata III)

⇒ J’arrête le transfert
⇒ Je tue les montages
⇒ Je supprime l’authentification dans FreeboxOS
⇒ Je recrée les montages et relance mon robocopy

Passé les fichiers déjà copiés (obv), stabilisation du transfert à ~600Mbit/s (et saturation si fichier volumineux)
Si copie de l’iso en // vers cible2, saturation du lien LAN

30 minutes plus tard, je suis à 140Go (de plus) d’envoyés.

Problème (de fond) : j’aimerais pouvoir protéger les share tout en conservant des performances honorables.

Cadeau Bonux en passant : si nous pouvions voir un jour une différenciation d’accès (lecture seule, accès complet) sur les partages, ce serait top (genre “pas d’auth, on est en lecture”).

Merci.

Bonjour,

Depuis la version 3.3.0 du serveur et suite à l’activation du nom de domaine les transferts de fichiers ftp entre le P et le serveur sont passés de 30 Mo/s à 8 Mo/s
La vitesse de transfer en HTTP n’a pas changé (30Mo/s).
Je suis en lien direct Gigabyte sur le serveur.
Le client FTP utilisé est FileZilla dans sa dernière version au moment ou j’ouvre ce ticket (3.15.0.1)

Bonjour, je viens ici pour trouver une piste car je n'arrive pas à voir le contenu de mon nas freebox delta sur la VM Debian 10 avec Plex Serveur.
Je n'arrive pas a comprendre ce qui ne va pas.

sudo su -
aptitude update
aptitude upgrade
systemctl reboot

sudo su -
cd /tmp
wget https://downloads.plex.tv/plex-media-server-new/1.24.1.4931-1a38e63c6/debian/plexmediaserver_1.24.1.4931-1a38e63c6_arm64.deb

dpkg -i plexmediaserver_1.24.1.4931-1a38e63c6_arm64.deb

systemctl status plexmediaserver

Puis ensuite j'ai modifié le fichier suivant

sudo nano /etc/fstab

//mafreebox.freebox.fr/freebox/Plex/Films /mnt/Films cifs guest,uid=1000,gid=1000,comment=cloudconfig 0 0

Le dossier et le chemin complet depuis mon Mac est :

smb://Freebox Server._smb._tcp.local/freebox/Plex/Films/

Sur Debian, avec la commande

cd /mnt/Films
ls -l

Le résultat est vide, pourtant j'ai bien plusieurs fichiers je ne comprend pas.

Je suis novice sur Debian.
Es-ce que qqn aurait une piste ?

Merci beaucoup à vous

J'ai parcouru plusieurs sites, beaucoup donne des commandes différentes, et j'ai essayé sans retour.
Merci beaucoup,

Prenez-soin de vous

Bonjour bonjour,

Je soupçonne fortement que vous avez changer les images pré-configurée des VM, notamment Ubuntu 19.04.

Il semble qu’elles soient corrompues. Cela devient une tannée de mettre en place un serveur média Plex.

L’encodage UTF8 n’est pas pris en charge, ce qui empêche de monter le disque dur Freebox (fichier fstab). Du coup j’ai voulu installer le pkg « linux-generic » pour résoudre ce problème et là : kernel panic au démarrage tout est cassé.

Je n’arrive plus à aboutir une mise à jour de la distribution « do-release-upgrade » —> read error (5) (cela indique généralement une corruption du disque dur).

Je suppose que vous l’avez changer car avant, avec une installation fraîche, il y avait des mises à jour de disponible mais plus maintenant.

Loin de moi l’idée d’accuser a tord pour autant, mais si vous les avez changer, pouvez-vous remettre les anciennes ?

En attendant un retour, je vous souhaite une excellente journée.

Je rencontre également énormément de difficultés sur une VM Debian 10 mais je n’ai pas poussée l’analyse plus loin.

Bonjour,
Mise en place d'une VM avec Debian 10 Buster fournir par Free.
Lorsque j'installe la VM bien évidemment je coche accès aux disque Freebox.
4 disques présent de 1To chacun en RAID 5 et actif bien sûr… Un contenu est présent sur les disques de type fichier en .mkv.
Une fois la VM installée et sans erreur
Accès au contenu de la VM via la console proposée par FREE.
login + mdp.
Je bascule en super-utilisateur via la commande sudo su - pour garantir l'accès à l'ensemble des fichiers présents sur la VM.
je me dirige vers /mnt pour constater les partitions présentes sur la VM.
Je trouve bien Freebox et un disque dur externe.
Ce qui signifie clairement que la VM a monté les 2 disques celui présent dans la free et un externe présent sur le port SUB de la free.
Et là grosse surprise !
La commandes ls -l permettant de lister le contenu de /mnt/Freebox fait apparaitre zéro (0) fichiers !
Alors même que dans le cloud-init-user-data les commandes suivantes sont affichées et indiquent clairement le montage des 2 disques !
#cloud-config
system_info:

default_user:
  name: freebox

password: thomeli9802
chpasswd: { expire: False }
ssh_pwauth: True
packages_update: true
packages:

1. cifs-utils

mounts:

1. [ 'mafreebox.freebox.fr/Freebox', '/mnt/Freebox', cifs, 'guest,uid=1000,gid=1000', '0', '0' ]
   - [ 'mafreebox.freebox.fr/GUADELOUPE', '/mnt/GUADELOUPE', cifs, 'guest,uid=1000,gid=1000', '0', '0' ]

runcmd:

1. mount -a

Nous avons donc un problème car pour un serveur PLEX au delà il ne va pas être facile de scanner un contenu apparaissant vide sous la V sous débian dés l'installation, je répète dés l'installation.

Dans l'attente de vous relire,

Bonjour,

   J'ai trouvé une autre XSS, encore plus simple à mettre en œuvre pour un attaquant.

Il suffit depuis un poste connecté au réseau local de se rendre sur l’adresse de la Freebox via le partage SMB, ouvert en écriture par défaut :

\\192.168.1.254\Disque dur\

et d’y écrire un fichier ou dossier dont le nom contient un script JS malicieux, qui sera exécuté si quelqu’un explore le dossier parent depuis l’interface web admin.

PoC : https://youtu.be/Ny0pgV4QT18 (vidéo non répertoriée)

Exemple de payload permettant de charger du contenu depuis une URL distante :

<img src="" onerror="s=document.createElement('img'); s.src='https:\x2F\x2Ftrollface.dk\x2FtrollfaceONE.png'; document.body.appendChild(s)">

(j’ai un peu galéré étant donné qu’il faut faire sans forward slash, en effet c’est un caractère interdit pour un nom de fichier)

Je reste à votre disposition si vous avez besoin de plus d’infos.
(un petit coup de pouce / geste de votre part ne serait pas de refus, bien que n’attendant évidement rien en retour; je cherche ces bugs sur mon temps libre)
Mon email de contact est dans mon profil.

Bonne journée et continuation.

Bonjour, j’ouvre une nouvelle tâche pour un soucis Windows 10 (déjà présent pendant la beta d’après certains utilisateurs)
Testé sur Freebox Révolution.

Au moment de la suppression de la plupart des fichiers / dossiers mais aussi lors de certains transferts, l’explorateur reste bloqué à 99% avec 0 octet restant, et impossible d’annuler. Obligé de redémarrer explorer.exe pour enlever le message. Cependant, les transferts sont effectués.
Cela se produit également lors d'un renommage d'un fichier.

Précisions :
Le bug se produit sur tous les PC windows (à jour).
Le disque dur sur la Freebox Révolution est formaté en NTFS (et n'a pas été reformaté depuis la 4.3.0).
Le bug fait planter le processus explorer.exe : si vous supprimez/renommez un fichier local (sur le Bureau par exemple), ça va rester aussi à 99% jusqu'au redémarrage du processus.