Aller au contenu principal

Erreur : Filesystem permission check

Qu'est-ce que cette erreur ?​

Depuis les artifacts 2026, FiveM embarque un nouveau système de vérification de sécurité au niveau du système de fichiers. Lorsqu'un script tente de lire ou écrire un fichier en dehors de son périmètre autorisé, le serveur journalise un avertissement du type :

[ c-scripting-node] Filesystem write permission check from 'nom_ressource' for permission fs.write on resource '/home/container/resources/...' - write not allowed
[ c-scripting-node] Filesystem permission check from 'nom_ressource' for permission fs.read on resource 'server.cfg' - no device found

Ce n'est pas une erreur critique qui fait planter le serveur, mais c'est un signal d'alerte important à ne pas ignorer.

Pourquoi ces vérifications existent-elles ?​

Les artifacts 2026 ont introduit un sandbox de permissions sur l'accès aux fichiers. Chaque ressource ne peut normalement accéder qu'à ses propres fichiers ou aux chemins explicitement autorisés. Cette mécanique a été ajoutée pour :

  • Bloquer les backdoors cachées dans des scripts qui lisent ou modifient des fichiers sensibles (server.cfg, scripts d'autres ressources, etc.)
  • Empêcher des scripts mal configurés d'altérer des fichiers critiques du serveur
  • Améliorer la traçabilité des accès au système de fichiers
attention

La présence de ces messages dans vos logs n'est pas normale. Cela indique qu'un script tente d'accéder à des fichiers qu'il ne devrait pas toucher.

Causes possibles​

1. Backdoor ou script malveillant​

C'est la cause la plus préoccupante. Certains scripts téléchargés depuis des sources non officielles contiennent du code malveillant qui tente de :

  • Lire server.cfg pour voler vos clés de licence, tokens ou mots de passe de base de données
  • Écrire dans des ressources tierces pour injecter du code
  • Accéder aux fichiers d'autres ressources

2. Script avec une fonction mal conçue​

Certains scripts légitimes utilisent des fonctions d'accès aux fichiers de manière incorrecte ou trop large (ex. : un script qui tente de lire un chemin absolu au lieu d'un chemin relatif à sa propre ressource).

3. Ressource obsolète non mise à jour​

Des ressources anciennes, conçues avant l'introduction du sandbox 2026, peuvent utiliser des pratiques d'accès aux fichiers qui ne sont plus autorisées.

Comment diagnostiquer​

Identifiez la ressource concernée — Le nom de la ressource est indiqué entre guillemets dans le message de log :

Filesystem permission check from 'nom_ressource' ...
                                   ^^^^^^^^^^^^^^

Recherchez les accès suspects dans le code de la ressource : fonctions comme LoadResourceFile, SaveResourceFile, io.open, ou des appels système natifs.

Vérifiez la source de la ressource : a-t-elle été téléchargée depuis GitHub officiel, le CFX Forum, ou une source inconnue ?

astuce

Utilisez un outil de diff pour comparer la ressource téléchargée avec la version officielle et détecter tout code ajouté.

Que faire ?​

Étape 1 — Mettre à jour la ressource​

La majorité des faux positifs viennent de ressources non mises à jour. Rendez-vous sur la page officielle de la ressource et installez la dernière version compatible avec les artifacts 2026.

Étape 2 — Vérifier la présence d'une backdoor​

Ouvrez les fichiers .lua ou .js de la ressource concernée et cherchez :

  • Des appels à os.execute, io.open, LoadResourceFile sur des chemins en dehors de la ressource
  • Du code obfusqué (longues chaînes encodées en base64, appels à load() ou pcall() avec du code dynamique)
  • Des requêtes HTTP vers des URLs externes inconnues

Si vous trouvez du code suspect, supprimez immédiatement la ressource et changez tous vos mots de passe / tokens de serveur.

Étape 3 — Remplacer par une source fiable​

Si la ressource est compromise ou trop ancienne pour être mise à jour, remplacez-la par une alternative provenant d'une source officielle :

Étape 4 — Redémarrer et surveiller les logs​

Après correction, redémarrez votre serveur et vérifiez que les messages ont disparu.

Exemple de log et interprétation​

[ c-scripting-node] Filesystem write permission check from 'oxmysql' for permission fs.write
  on resource '/home/container/resources/[gameplay]/[Mapping]/247Supermarket/constants/staging.js'
  - write not allowed
ÉlémentSignification
oxmysqlLa ressource qui tente l'accès
fs.writeTentative d'écriture
/247Supermarket/constants/staging.jsFichier cible (une autre ressource)
write not allowedAccès bloqué par le sandbox

Dans cet exemple, oxmysql tente d'écrire dans les fichiers d'une autre ressource — ce qui est anormal et mérite investigation.

Récapitulatif​

SituationAction recommandée
Message apparu après une mise à jour d'artifactMettre à jour les ressources concernées
Message sur une ressource téléchargée d'une source inconnueSupprimer, auditer, changer les credentials
Message persistant sur une ressource officielleSignaler au développeur, chercher une alternative
Code obfusqué détectéSupprimer immédiatement + changer tous les tokens
info

En cas de doute, l'équipe support YorkHost est disponible pour vous aider à analyser vos logs. Ouvrez un ticket sur notre Discord.