Problème de permission, de fichiers qui veulent pas s'effacer...

Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5
#1
Citation :#~~~~~ NE PAS SUPPRIMER CE BLOC ~~~~~
#~ Version du CMS: 1.7.1
#~ Nom de l'hébergeur : infomaniak
#~ Informations Système :
#~ ----------------------------------------------
#~ Cms Version: 1.7.1
#~ Installed Modules:
#~ * CMSMailer: 2.0
#~ * FileManager: 1.0.2
#~ * MenuManager: 1.6.3
#~ * ModuleManager: 1.3.3
#~ * News: 2.10.5
#~ * nuSOAP: 1.0.1
#~ * Printing: 1.0.4
#~ * Search: 1.6.3
#~ * ThemeManager: 1.1.1
#~ * TinyMCE: 2.7.0
#~ * FrontEndUsers: 1.9.2
#~ * CustomContent: 1.5.3
#~ * CGExtensions: 1.18.8
#~ * CGCalendar: 1.5.2
#~ Config Information:
#~ * php_memory_limit:
#~ * process_whole_template: false
#~ * max_upload_size: 48000000
#~ * default_upload_permission: 664
#~ * assume_mod_rewrite: true
#~ * page_extension: /
#~ * internal_pretty_urls: false
#~ * use_hierarchy: true
#~ Php Information:
#~ * phpversion: 5.2.13
#~ * md5_function: On (Vrai)
#~ * gd_version: 2
#~ * tempnam_function: On (Vrai)
#~ * magic_quotes_runtime: Off (Faux)
#~ * E_STRICT: 0
#~ * memory_limit: 64M
#~ * max_execution_time: 10
#~ * safe_mode: Off (Faux)
#~ * session_save_path: Aucune vérification à cause de la restriction spécifiée par PHP open_basedir
#~ * session_use_cookies: On (Vrai)
#~ Server Information:
#~ * Server Api: apache2handler
#~ * Server Db Type: MySQL (mysql)
#~ * Server Db Version: 5.0.84
#~ ----------------------------------------------
#~~~~~ NE PAS SUPPRIMER CE BLOC ~~~~~
Salut,

Je m'y connais pas trop en gestion de fichiers en général et là, je galère. J'ai eu deux problèmes récemment avec CMSMS avec les permissions des fichiers.

Le premier, avec les modules lors de mise à jour. Je voulais passer par le CMS et uploadé le fichier xml pour FrontEnd User, mais la mise à jour refusait de s'effectuer. J'ai fini par passer par le gestionnaire de fichiers de mon hébergeur pour donner tous les droits à tout le monde sur tous les fichiers du module, mais ça n'a pas arrangé les choses. Hors, je ne vois pas trop ce que j'aurais pu faire d'autre. Des idées ?

Le second, c'est avec le gestionnaire de fichiers. J'avais pas pensé à l'option qui permet de déplacer les fichiers et je suis passé par le ftp après avoir modifié les permissions depuis le CMS. Maintenant, mes fichiers ont des permissions 000 sur CMS et je ne peux plus les accéder par le FTP (permission du répertoire: flcdmpe(02774) et 664 dans le gestionnaire de fichiers). C'est super gênant et j'ai pas l'impression d'avoir mérité d'être coincé avec ces fichiers pourris dans des répertoires pourris qui veulent plus d'effacer.

Quand je vais dans le gestionnaire de fichiers, dans un dossier avec ces fichiers corrompus, j'ai une erreur de ce genre pour chacun d'eux:

Warning: stat() [function.stat]: stat failed for /home/www/2facc9cde4200ebea4065b97f8888179/web/test_cmsms/uploads/Fichiers_Coord21/Scéances/Année en cours/00 Assemblée Générale 10-06-2010/01 Liste besoins site Coord21 26.03.10.odt in /home/www/2facc9cde4200ebea4065b97f8888179/web/test_cmsms/modules/FileManager/FileManager.module.php on line 485

Est-ce que quelqu'un peut m'aider ?
Répondre
#1
Citation :#~~~~~ NE PAS SUPPRIMER CE BLOC ~~~~~
#~ Version du CMS: 1.7.1
#~ Nom de l'hébergeur : infomaniak
#~ Informations Système :
#~ ----------------------------------------------
#~ Cms Version: 1.7.1
#~ Installed Modules:
#~ * CMSMailer: 2.0
#~ * FileManager: 1.0.2
#~ * MenuManager: 1.6.3
#~ * ModuleManager: 1.3.3
#~ * News: 2.10.5
#~ * nuSOAP: 1.0.1
#~ * Printing: 1.0.4
#~ * Search: 1.6.3
#~ * ThemeManager: 1.1.1
#~ * TinyMCE: 2.7.0
#~ * FrontEndUsers: 1.9.2
#~ * CustomContent: 1.5.3
#~ * CGExtensions: 1.18.8
#~ * CGCalendar: 1.5.2
#~ Config Information:
#~ * php_memory_limit:
#~ * process_whole_template: false
#~ * max_upload_size: 48000000
#~ * default_upload_permission: 664
#~ * assume_mod_rewrite: true
#~ * page_extension: /
#~ * internal_pretty_urls: false
#~ * use_hierarchy: true
#~ Php Information:
#~ * phpversion: 5.2.13
#~ * md5_function: On (Vrai)
#~ * gd_version: 2
#~ * tempnam_function: On (Vrai)
#~ * magic_quotes_runtime: Off (Faux)
#~ * E_STRICT: 0
#~ * memory_limit: 64M
#~ * max_execution_time: 10
#~ * safe_mode: Off (Faux)
#~ * session_save_path: Aucune vérification à cause de la restriction spécifiée par PHP open_basedir
#~ * session_use_cookies: On (Vrai)
#~ Server Information:
#~ * Server Api: apache2handler
#~ * Server Db Type: MySQL (mysql)
#~ * Server Db Version: 5.0.84
#~ ----------------------------------------------
#~~~~~ NE PAS SUPPRIMER CE BLOC ~~~~~
Salut,

Je m'y connais pas trop en gestion de fichiers en général et là, je galère. J'ai eu deux problèmes récemment avec CMSMS avec les permissions des fichiers.

Le premier, avec les modules lors de mise à jour. Je voulais passer par le CMS et uploadé le fichier xml pour FrontEnd User, mais la mise à jour refusait de s'effectuer. J'ai fini par passer par le gestionnaire de fichiers de mon hébergeur pour donner tous les droits à tout le monde sur tous les fichiers du module, mais ça n'a pas arrangé les choses. Hors, je ne vois pas trop ce que j'aurais pu faire d'autre. Des idées ?

Le second, c'est avec le gestionnaire de fichiers. J'avais pas pensé à l'option qui permet de déplacer les fichiers et je suis passé par le ftp après avoir modifié les permissions depuis le CMS. Maintenant, mes fichiers ont des permissions 000 sur CMS et je ne peux plus les accéder par le FTP (permission du répertoire: flcdmpe(02774) et 664 dans le gestionnaire de fichiers). C'est super gênant et j'ai pas l'impression d'avoir mérité d'être coincé avec ces fichiers pourris dans des répertoires pourris qui veulent plus d'effacer.

Quand je vais dans le gestionnaire de fichiers, dans un dossier avec ces fichiers corrompus, j'ai une erreur de ce genre pour chacun d'eux:

Warning: stat() [function.stat]: stat failed for /home/www/2facc9cde4200ebea4065b97f8888179/web/test_cmsms/uploads/Fichiers_Coord21/Scéances/Année en cours/00 Assemblée Générale 10-06-2010/01 Liste besoins site Coord21 26.03.10.odt in /home/www/2facc9cde4200ebea4065b97f8888179/web/test_cmsms/modules/FileManager/FileManager.module.php on line 485

Est-ce que quelqu'un peut m'aider ?
Répondre
#2
iva a écrit :flcdmpe(02774) et 664 dans le gestionnaire de fichiers). C'est super gênant et j'ai pas l'impression d'avoir mérité d'être coincé avec ces fichiers pourris dans des répertoires pourris qui veulent plus d'effacer.
+1 même soucis de répertoires impossible à éffacer.......
-.
Répondre
#2
iva a écrit :flcdmpe(02774) et 664 dans le gestionnaire de fichiers). C'est super gênant et j'ai pas l'impression d'avoir mérité d'être coincé avec ces fichiers pourris dans des répertoires pourris qui veulent plus d'effacer.
+1 même soucis de répertoires impossible à éffacer.......
-.
Répondre
#3
Pourquoi tu changes mon nom quand tu me cites ?

Sinon, j'ai finalement pensé à passer par mon hébergeur pour me mettre propriétaire des fichiers et les effacer. Donc, j'ai pu les virer.

Par contre, ça reste un problème embêtant dans le sens où je sais pas trop pourquoi ça a dégénéré comme ça. Et donc la question reste ouverte !
Répondre
#3
Pourquoi tu changes mon nom quand tu me cites ?

Sinon, j'ai finalement pensé à passer par mon hébergeur pour me mettre propriétaire des fichiers et les effacer. Donc, j'ai pu les virer.

Par contre, ça reste un problème embêtant dans le sens où je sais pas trop pourquoi ça a dégénéré comme ça. Et donc la question reste ouverte !
Répondre
#4
l'upload de FEU qui plante j'ai eu le même soucis, pour moi c'est l'auteur du module qui a merdé son upload du fichier xml.

pour la suite du problème je ne sais pas quoi dire hormis qu'un hébergement dans lequel t'es pas propriétaire de tes fichiers de base, c'est moyen Sad

jamais rencontré de soucis de ce genre ni chez OVH ni chez SU³ ou j'étais toujours root de mes fichiers
Répondre
#4
l'upload de FEU qui plante j'ai eu le même soucis, pour moi c'est l'auteur du module qui a merdé son upload du fichier xml.

pour la suite du problème je ne sais pas quoi dire hormis qu'un hébergement dans lequel t'es pas propriétaire de tes fichiers de base, c'est moyen Sad

jamais rencontré de soucis de ce genre ni chez OVH ni chez SU³ ou j'étais toujours root de mes fichiers
Répondre
#5
Ben, quand je mets des fichiers depuis le CMS, le propriétaire, c'est httpd (ou un truc du genre), ce qui correspond pas au propriétaire de la base de donnée (qqchose_coord, je crois). On peut changer ça ? ça m'arrangerait pas mal de dire que les trucs ajouter au travers du site m'appartient.
Répondre
#5
Ben, quand je mets des fichiers depuis le CMS, le propriétaire, c'est httpd (ou un truc du genre), ce qui correspond pas au propriétaire de la base de donnée (qqchose_coord, je crois). On peut changer ça ? ça m'arrangerait pas mal de dire que les trucs ajouter au travers du site m'appartient.
Répondre
#6
Salut !

Je me permets de relancer la question, parce que ce serait vraiment pratique de pouvoir décider du propriétaire des fichiers qui sont importés depuis internet !

Merci Smile
Répondre
#6
Salut !

Je me permets de relancer la question, parce que ce serait vraiment pratique de pouvoir décider du propriétaire des fichiers qui sont importés depuis internet !

Merci Smile
Répondre
#7
Tu sais Yvan, moi j'ai jamais eu de soucis sur ce point, j'ai toujours conservé mes droits sur les fichiers uploadé.

tu devrais plutôt questionner ton hébergeur, c'est pas un comportement normal de cmsms et je te paris qu'au mieux il te dira de changer le Masque de création de fichier (umask) : (022 de mémoire pour cmsms) au pire qu'il fallait pas venir chez eux par ce qu'il autorise pas la manip.

enfin là je suppute un peu Big Grin
Répondre
#7
Tu sais Yvan, moi j'ai jamais eu de soucis sur ce point, j'ai toujours conservé mes droits sur les fichiers uploadé.

tu devrais plutôt questionner ton hébergeur, c'est pas un comportement normal de cmsms et je te paris qu'au mieux il te dira de changer le Masque de création de fichier (umask) : (022 de mémoire pour cmsms) au pire qu'il fallait pas venir chez eux par ce qu'il autorise pas la manip.

enfin là je suppute un peu Big Grin
Répondre
#8
Mais c'est quoi le comportement normal de CMSMS ? Je trouve ça vraiment pourri, mais c'est en même temps logique qu'un fichier uploadé par FTP n'ait pas le même nom de propriétaire qu'un fichier uploadé depuis le CMS.

Y a pas une option dans CMSMS pour choisir le nom de propriétaire des fichiers uploadés depuis le CMS ?

J'ai fouillé un peu la doc et le net et si je comprends bien, je pourrais mettre un umask de 002 pour pouvoir modifier les fichiers depuis le ftp, c'est juste ? Même si, du point de vue du FTP, je ne suis pas propriétaire des fichiers ?
Répondre
#8
Mais c'est quoi le comportement normal de CMSMS ? Je trouve ça vraiment pourri, mais c'est en même temps logique qu'un fichier uploadé par FTP n'ait pas le même nom de propriétaire qu'un fichier uploadé depuis le CMS.

Y a pas une option dans CMSMS pour choisir le nom de propriétaire des fichiers uploadés depuis le CMS ?

J'ai fouillé un peu la doc et le net et si je comprends bien, je pourrais mettre un umask de 002 pour pouvoir modifier les fichiers depuis le ftp, c'est juste ? Même si, du point de vue du FTP, je ne suis pas propriétaire des fichiers ?
Répondre
#9
je n'ai pas les connaissances nécessaire pour te répondre au plus juste sur ce point, inutile d'attendre de moi LA solution à ton pb.

Citation :Je trouve ça vraiment pourri, mais c'est en même temps logique qu'un fichier uploadé par FTP n'ait pas le même nom de propriétaire qu'un fichier uploadé depuis le CMS.
je suis pas d'accord. tu dois être propriétaire des fichiers uploadé par FTP et au minimum avoir la possibilité via FTP de modifier les fichier uploadé par le process Apache. Donc soit le user apache = user FTP (chez SU³ c'est à peu de chose près ce que l'on fait) soit la config du serveur permet aux deux users d'agir sur les fichiers de l'autre grâce aux chmod

il y a peut être une chance comme je t'ai dit en jouant avec le umask mais comme je suis pas expert je peux rien te certifier. une seule solution : test, ca te prendra 2 minutes à tester les != umask
Répondre
#9
je n'ai pas les connaissances nécessaire pour te répondre au plus juste sur ce point, inutile d'attendre de moi LA solution à ton pb.

Citation :Je trouve ça vraiment pourri, mais c'est en même temps logique qu'un fichier uploadé par FTP n'ait pas le même nom de propriétaire qu'un fichier uploadé depuis le CMS.
je suis pas d'accord. tu dois être propriétaire des fichiers uploadé par FTP et au minimum avoir la possibilité via FTP de modifier les fichier uploadé par le process Apache. Donc soit le user apache = user FTP (chez SU³ c'est à peu de chose près ce que l'on fait) soit la config du serveur permet aux deux users d'agir sur les fichiers de l'autre grâce aux chmod

il y a peut être une chance comme je t'ai dit en jouant avec le umask mais comme je suis pas expert je peux rien te certifier. une seule solution : test, ca te prendra 2 minutes à tester les != umask
Répondre
#10
J'avais un peu peur de faire des tests, parce que la dernière fois que j'ai joué avec les permissions, ça s'est terminé par un effacement total du dossier dans lequel je m'étais amusé...

Avec un umask de 002, je peux m'amuser à ballader mes fichiers et mes dossiers depuis mon FTP. C'est pratique. Par contre, je peux pas effacer les dossiers créés avec CMSMS depuis le FTP et vice-versa. Pas spécialement logique...

Le truc con, c'est qui si je pouvais déplacer des dossiers depuis CMSMS, j'aurais pas à me soucier de ça...
Répondre
#10
J'avais un peu peur de faire des tests, parce que la dernière fois que j'ai joué avec les permissions, ça s'est terminé par un effacement total du dossier dans lequel je m'étais amusé...

Avec un umask de 002, je peux m'amuser à ballader mes fichiers et mes dossiers depuis mon FTP. C'est pratique. Par contre, je peux pas effacer les dossiers créés avec CMSMS depuis le FTP et vice-versa. Pas spécialement logique...

Le truc con, c'est qui si je pouvais déplacer des dossiers depuis CMSMS, j'aurais pas à me soucier de ça...
Répondre
#11
que dit ton hébergeur ?
Répondre
#11
que dit ton hébergeur ?
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 1 visiteur(s)