Le vendredi 28 Octobre 2005 18:02, linux_forever2001 a écrit :
> Le vendredi 28 Octobre 2005 17:55, linux_forever2001 a écrit :
> > Le vendredi 28 Octobre 2005 15:07, CC a écrit :
> > > Selon CC <[EMAIL PROTECTED]>:
> > > > quand tu regardes les droits avec konqueror :
> > > > la propriété des fichiers est à l'user qui a lancé smb4k, le groupe
> > > > son groupe
> > > > primaire. Le propriétaire et les droits ne sont pas ceux du serveur.
> > >
> > > je corrige mon message précédent qui était incorrect et incomplet :
> > > avec smb4k pour monter une ressource samba, puis konqueror pour
> > > parcourir le montage, ce sont bien (comme sous windows d'ailleurs) les
> > > uid/gid définis sur le serveur qui sont récupérés et affichés. Il
> > > s'agit bien d'uids/gids numériques qui sont récupérés, mais le nom
> > > correspondant est converti (contrairement à windows) sur la base de
> > > comptes *locale* (côté client).(windows essaie de résoudre le nom
> > > correspondant au rid en interrogeant le serveur samba, ce qui n'est pas
> > > le cas de smb4k qui ne prend en compte que l'uid et résoud les noms à
> > > partir de la base système locale, c'est-à-dire /etc/passwd sur un
> > > système standard).
> > >
> > > un exemple : mon utilisateur user1 sur le serveur a pour uid 510. l'uid
> > > va être transmise par samba et résolue *localement* avec l'utilisateur
> > > dont l'uid est 510 (qui peut ne pas exister ou alors s'appeler
> > > autrement). Mais dans tous les cas, les fichiers créés par le client
> > > auront bien comme propriétaire (sur le serveur) celui spécifié dans le
> > > champs
> > > authentification de smb4k.
> > >
> > > Il en résulte que l'affichage du nom de propriétaire dans konqueror ne
> > > correpond pas au propriétaire sur le serveur (le nom seulement, car
> > > l'uid est correct). Si l'on veut que le nom soit le bon, il faut
> > > effectivement que les uids soient les mêmes côté client et côté serveur
> > > (ce qui est peu réaliste dans une grosse structure, sauf à avoir la
> > > même base de comptes, par exemple en copiant passwd et passdb.tdb).
> > >
> > > Il en résulte également qu'il n'est pas possible de changer le
> > > propriétaire à partir de smb4k/konqueror
> > >
> > > > > il faudrait dc, que les ids de mes clients, soient les même que
> > > > > ceux du serveur c'est ça ???
> > > >
> > > > non
> > >
> > > comme précisé ci-dessus, cela n'est nécessaire que si tu veux que le
> > > nom affiché soit le bon. ce n'est pas nécessaire au fonctionnement de
> > > samba. Un bonne habitude pour éviter les problèmes : crée tes comptes
> > > d'utilisateur sur le serveur avec des uids > 10000. Il y a peu de
> > > chances que tes users locaux aient cette uid, tu verra donc apparaître
> > > non pas un nom erroné, mais l'uid numérique non résolue.
> > >
> > > Encore une fois, même si (pour le cas précédent) l'uid locale 510
> > > correspond à user2 alors qu'elle correspond à user1 sur le serveur, si
> > > tu crées un fichier à partir de konqueror, il sera affiché user2 sur le
> > > client, mais le fichier appartiendra bien à user1 sur le serveur.
> > >
> > > Tu risques d'avoir beaucoup de difficultés pour changer les droits à
> > > partir de smb4k/konqueror.
> > >
> > > En résumé : samba est conçu pour des clients win, pas vraiment pour des
> > > clients linux. Utilise plutôt nfs.
> > >
> > > --
> > > CC
> >
> > merci à toi de ta longue explication. il se passe donc bien ce que je
> > pensais malheureusement :( de ce fait, mon linux local m'interdit
> > d'écrire sur ces ressources :(
>
> je tiens à préciser que pour éviter ce genre d eproblème g vu que ds smb4k
> on peut spécifier un uid et guid :) dc cela résoud le prob :)


heu... petite modif, cela n'a pas l'air de fctionner pile poil...
et heu.... changer d'id de mon systèm local, cela ne risque rien ou pas ??? 
(je crois que je v essayer sur un compte sans importance lol)

____________________________________________________
Want to buy your Pack or Services from Mandriva? 
Go to http://store.mandriva.com
Join the Club : http://www.mandrivaclub.com
____________________________________________________

Répondre à