Retourner aux forums || Retourner au forum
je viens solliciter votre aide sur un problème que je ne comprends pas.
Sur une machine, j'ai plusieurs compte utilisateur (user1,user2 et user3 par exemple). Tous les users font parti du même groupe.
Cependant, à chaque fois que user2 essaye d'écraser un fichier de user1 par une version plus récente du fichier visé, le système répond qu'il ne peut pas le faire (meme avec un chmod 777 sur le fichier).
Comment faire, et d'ou peut provenir ce problème??
D'avance merci.
Ubuntu is an ancient african word meaning : "I can't configure Debian".
Tout dépend de la méthode
Si pour écraser le fichier il supprime le fichier puis le remplace c'est sur le répertoire qu'il a besoin des droits.
-
[^]Re: Tout dépend de la méthode
Posté par Uld (page perso, ) le 22/06/2006 à 14:32. (lien). Évalué à 2.Non non, par ecraser le fichier j'entedns: se connecter en ftp sur le serveur, aller dans le repertoire concerné, et placer le nouveau fichier sur l'ancien.
Là en l'état, le système refuse. On est obligé de demander au possésseur du fichier de bien vouloir le supprimer pour pouvoir y mettre la nouvelle version.
Les utilisateur sont géré par LDAP (enfin je crois, en fait c'est un système qui gère les comptes utilisateur aussi bien pour les session windows que linux), si ca peut aider...--
Ubuntu is an ancient african word meaning : "I can't configure Debian".-
[^]Re: Tout dépend de la méthode
Posté par Uld (page perso, ) le 22/06/2006 à 14:35. (lien). Évalué à 2.Ah, encore une chose, si ca peut aider, on m'a conseillé de regarder du coté de bash_profile et de umask... Ceci dis, je rame toujours.
--
Ubuntu is an ancient african word meaning : "I can't configure Debian".-
[^]Sticky Sticky WWW
Posté par Obsidian () le 22/06/2006 à 16:39. (lien). Évalué à 2.Regarde également du coté du sticky bit sur le répertoire en question, typiquement s'il s'appelle " /tmp ".
Sans ça, ce peut quand même être un problème de droit sur le répertoire comme dit plus haut. Ecraser un fichier se fait de deux manières, soit par ouverture/vidage/remplissage du fichier de destination, soit par suppression/recréation, et il fait que le numéro d'inode ne change pas n'est pas probant en soi pour connaître la méthode utilisée ... Je penche quand même pour la première dans le sens où lorsque je fais le test en local, le fichier de destination conserve quand même ses droit et prioriétaire originaux.
Enfin, il se peut très bien qu'il s'agisse d'une facétie de ton FTP, et pas du filesystem. Essaie de faire le test en local ...
-
-
config ftp
Tu as regardé si tu n'as pas un allow overwrite dans ta config ftp ?
si cela vient de cela user1 ne peut pas non plus re-écrire es fichiers.
Autre truc, ton repertoire es peut-être en Sticky-bit et on ne peut écraser que ses propres fichiers.
Revenir en haut de page || Retourner aux forums || Retourner au forum
Cette page a été générée par Templeet en 0.0571s (dont 0.0048 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.