Forum général.général Droits sur fichier

Posté par  (site web personnel) .
Étiquettes : aucune
0
22
juin
2006
Bonjour,

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.

  • # Tout dépend de la méthode

    Posté par  (site web personnel) . Évalué à 5.

    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  (site web personnel) . É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...

      • [^] # Re: Tout dépend de la méthode

        Posté par  (site web personnel) . É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.

        • [^] # Sticky Sticky WWW

          Posté par  . É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

    Posté par  . Évalué à 2.

    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.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.