toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Salut Kurtz
Côté windows, qu'est ce que tu as comme service afp ?
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
pour la stabilité, as-tu testé cifs à la place de smb ?
quelqu'un à les mêmes problème ?
Non, je ne fais plus de afp sur windows parce que j'ai pas les budjets pour du ExtremeZ-IP et que en dehors de ça, je ne connais que les "M$ SFM"
Or M$ SFM est dangereux : - Le backup n'est pas restaurable intégralement (du moins avec ArcServe mais c'est surement pareil pour tous les soft) - Il y a de graves problèmes de nom incompatible à la fois côté mac (SFM ne lit pas les dossiers de plus de 32 char.) et à la fois côté win ( SFM autorise les caractères comme /! ) - Quand on accède à la fois en afp et en cifs depuis un mac sur du windows, on a (comme pour linux samba+netatalk) des problèmes lorsqu'on pose un fichier sur le serveur en afp et qu'on le récupère en smb, ou inversément, les noms et resources foirent.
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
-- Nicolas Michel
kurtz_le_pirate <kurtzlepirate@yahoo.fr> wrote:
bonjour,
toujours suite au passage de tiger à leopard (10.5.2), il
est impossible au utilisateurs de se connecter en 'afp' sur
le serveur windows.
Salut Kurtz
Côté windows, qu'est ce que tu as comme service afp ?
'smb' permet de se connecter mais les connexions ne sont
pas stable, les fichiers s'abiment,...
pour la stabilité, as-tu testé cifs à la place de smb ?
quelqu'un à les mêmes problème ?
Non, je ne fais plus de afp sur windows parce que j'ai pas les budjets
pour du ExtremeZ-IP et que en dehors de ça, je ne connais que les
"M$ SFM"
Or M$ SFM est dangereux :
- Le backup n'est pas restaurable intégralement
(du moins avec ArcServe mais c'est surement pareil pour tous les soft)
- Il y a de graves problèmes de nom incompatible à la fois côté mac
(SFM ne lit pas les dossiers de plus de 32 char.)
et à la fois côté win ( SFM autorise les caractères comme /! )
- Quand on accède à la fois en afp et en cifs depuis un mac sur du
windows, on a (comme pour linux samba+netatalk) des problèmes lorsqu'on
pose un fichier sur le serveur en afp et qu'on le récupère en smb, ou
inversément, les noms et resources foirent.
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie
Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Salut Kurtz
Côté windows, qu'est ce que tu as comme service afp ?
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
pour la stabilité, as-tu testé cifs à la place de smb ?
quelqu'un à les mêmes problème ?
Non, je ne fais plus de afp sur windows parce que j'ai pas les budjets pour du ExtremeZ-IP et que en dehors de ça, je ne connais que les "M$ SFM"
Or M$ SFM est dangereux : - Le backup n'est pas restaurable intégralement (du moins avec ArcServe mais c'est surement pareil pour tous les soft) - Il y a de graves problèmes de nom incompatible à la fois côté mac (SFM ne lit pas les dossiers de plus de 32 char.) et à la fois côté win ( SFM autorise les caractères comme /! ) - Quand on accède à la fois en afp et en cifs depuis un mac sur du windows, on a (comme pour linux samba+netatalk) des problèmes lorsqu'on pose un fichier sur le serveur en afp et qu'on le récupère en smb, ou inversément, les noms et resources foirent.
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
-- Nicolas Michel
kurtz_le_pirate
Michel Nicolas Alex wrote:
kurtz_le_pirate wrote:
bonjour,
toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Salut Kurtz
Côté windows, qu'est ce que tu as comme service afp ?
ben le sfm de 2003 :(
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
pour la stabilité, as-tu testé cifs à la place de smb ?
non cifs pas testé. je vais fouiller
quelqu'un à les mêmes problème ?
Non, je ne fais plus de afp sur windows parce que j'ai pas les budjets pour du ExtremeZ-IP et que en dehors de ça, je ne connais que les "M$ SFM"
oui je connais extremez-ip et moi non plus je n'ai pas de budget.
Or M$ SFM est dangereux : - Le backup n'est pas restaurable intégralement (du moins avec ArcServe mais c'est surement pareil pour tous les soft)
pas de problème à ce niveau chez nous avec backupexec.
- Il y a de graves problèmes de nom incompatible à la fois côté mac (SFM ne lit pas les dossiers de plus de 32 char.) et à la fois côté win ( SFM autorise les caractères comme /! )
oui ça c'est bien connu
- Quand on accède à la fois en afp et en cifs depuis un mac sur du windows, on a (comme pour linux samba+netatalk) des problèmes lorsqu'on pose un fichier sur le serveur en afp et qu'on le récupère en smb, ou inversément, les noms et resources foirent.
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
oui xserve, je sais, je sais mais je ne suis pas maitre non plus de toute l'infrastructure.
-- klp "bug : probleme d'interface entre la chaise et le clavier"
Michel Nicolas Alex wrote:
kurtz_le_pirate <kurtzlepirate@yahoo.fr> wrote:
bonjour,
toujours suite au passage de tiger à leopard (10.5.2), il
est impossible au utilisateurs de se connecter en 'afp' sur
le serveur windows.
Salut Kurtz
Côté windows, qu'est ce que tu as comme service afp ?
ben le sfm de 2003 :(
'smb' permet de se connecter mais les connexions ne sont
pas stable, les fichiers s'abiment,...
pour la stabilité, as-tu testé cifs à la place de smb ?
non cifs pas testé. je vais fouiller
quelqu'un à les mêmes problème ?
Non, je ne fais plus de afp sur windows parce que j'ai pas les budjets
pour du ExtremeZ-IP et que en dehors de ça, je ne connais que les
"M$ SFM"
oui je connais extremez-ip et moi non plus je n'ai pas
de budget.
Or M$ SFM est dangereux :
- Le backup n'est pas restaurable intégralement
(du moins avec ArcServe mais c'est surement pareil pour tous les soft)
pas de problème à ce niveau chez nous avec backupexec.
- Il y a de graves problèmes de nom incompatible à la fois côté mac
(SFM ne lit pas les dossiers de plus de 32 char.)
et à la fois côté win ( SFM autorise les caractères comme /! )
oui ça c'est bien connu
- Quand on accède à la fois en afp et en cifs depuis un mac sur du
windows, on a (comme pour linux samba+netatalk) des problèmes
lorsqu'on pose un fichier sur le serveur en afp et qu'on le récupère
en smb, ou inversément, les noms et resources foirent.
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie
Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
oui xserve, je sais, je sais mais je ne suis pas maitre non
plus de toute l'infrastructure.
--
klp
"bug : probleme d'interface entre la chaise et le clavier"
toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Salut Kurtz
Côté windows, qu'est ce que tu as comme service afp ?
ben le sfm de 2003 :(
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
pour la stabilité, as-tu testé cifs à la place de smb ?
non cifs pas testé. je vais fouiller
quelqu'un à les mêmes problème ?
Non, je ne fais plus de afp sur windows parce que j'ai pas les budjets pour du ExtremeZ-IP et que en dehors de ça, je ne connais que les "M$ SFM"
oui je connais extremez-ip et moi non plus je n'ai pas de budget.
Or M$ SFM est dangereux : - Le backup n'est pas restaurable intégralement (du moins avec ArcServe mais c'est surement pareil pour tous les soft)
pas de problème à ce niveau chez nous avec backupexec.
- Il y a de graves problèmes de nom incompatible à la fois côté mac (SFM ne lit pas les dossiers de plus de 32 char.) et à la fois côté win ( SFM autorise les caractères comme /! )
oui ça c'est bien connu
- Quand on accède à la fois en afp et en cifs depuis un mac sur du windows, on a (comme pour linux samba+netatalk) des problèmes lorsqu'on pose un fichier sur le serveur en afp et qu'on le récupère en smb, ou inversément, les noms et resources foirent.
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
oui xserve, je sais, je sais mais je ne suis pas maitre non plus de toute l'infrastructure.
-- klp "bug : probleme d'interface entre la chaise et le clavier"
Patrick Stadelmann
In article <1iif6is.1gha1zo1kilv5yN%, (Michel Nicolas Alex) wrote:
pour la stabilité, as-tu testé cifs à la place de smb ?
Ca change quelque chose de se connecter avec cifs:// au lieu de smb:// ?
Patrick -- Patrick Stadelmann
In article
<1iif6is.1gha1zo1kilv5yN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
pour la stabilité, as-tu testé cifs à la place de smb ?
Ca change quelque chose de se connecter avec cifs:// au lieu de smb:// ?
Patrick
--
Patrick Stadelmann <Patrick.Stadelmann@unine.ch>
In article <1iif6is.1gha1zo1kilv5yN%, (Michel Nicolas Alex) wrote:
pour la stabilité, as-tu testé cifs à la place de smb ?
Ca change quelque chose de se connecter avec cifs:// au lieu de smb:// ?
Patrick -- Patrick Stadelmann
Nicolas-Michel_REMOVE
kurtz_le_pirate wrote:
Or M$ SFM est dangereux : - Le backup n'est pas restaurable intégralement (du moins avec ArcServe mais c'est surement pareil pour tous les soft)
pas de problème à ce niveau chez nous avec backupexec.
Même pour des fichiers contenant resource fork ou type/creator ? Et même pour des fichiers/dossiers aux noms non conformes ?
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
oui xserve, je sais, je sais mais je ne suis pas maitre non plus de toute l'infrastructure.
Oui, je connais ça. Pareil ici.
Je te souhaite bien du courage avec les SFM. Moi j'ai viré ça il y a très longtemps vu que ça créait plus de problèmes que ça n'en résolvait.
En fait j'ai viré afp partout, à l'exception d'une platteforme d'échange netatalk+samba / linux parce qu'on a encore du Mac OS 8 et 9. Parce que mêmesur Mac OS X j'ai eu pas mal de problèmes avec l'afp. En fait le seul cas où je pense (j'espère) que l'afp marche bien, c'est avec un système "Mac OS X Server"
-- Nicolas Michel
kurtz_le_pirate <kurtzlepirate@yahoo.fr> wrote:
Or M$ SFM est dangereux :
- Le backup n'est pas restaurable intégralement
(du moins avec ArcServe mais c'est surement pareil pour tous les soft)
pas de problème à ce niveau chez nous avec backupexec.
Même pour des fichiers contenant resource fork ou type/creator ?
Et même pour des fichiers/dossiers aux noms non conformes ?
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie
Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
oui xserve, je sais, je sais mais je ne suis pas maitre non
plus de toute l'infrastructure.
Oui, je connais ça. Pareil ici.
Je te souhaite bien du courage avec les SFM.
Moi j'ai viré ça il y a très longtemps vu que ça créait plus de
problèmes que ça n'en résolvait.
En fait j'ai viré afp partout, à l'exception d'une platteforme d'échange
netatalk+samba / linux parce qu'on a encore du Mac OS 8 et 9.
Parce que mêmesur Mac OS X j'ai eu pas mal de problèmes avec l'afp.
En fait le seul cas où je pense (j'espère) que l'afp marche bien, c'est
avec un système "Mac OS X Server"
Or M$ SFM est dangereux : - Le backup n'est pas restaurable intégralement (du moins avec ArcServe mais c'est surement pareil pour tous les soft)
pas de problème à ce niveau chez nous avec backupexec.
Même pour des fichiers contenant resource fork ou type/creator ? Et même pour des fichiers/dossiers aux noms non conformes ?
Bref, sur win je ne fais que du cifs et tant-pis pour les ._saloperie Si tu ne veux pas ça, <Pub> Xserve c'est bien </Pub>
oui xserve, je sais, je sais mais je ne suis pas maitre non plus de toute l'infrastructure.
Oui, je connais ça. Pareil ici.
Je te souhaite bien du courage avec les SFM. Moi j'ai viré ça il y a très longtemps vu que ça créait plus de problèmes que ça n'en résolvait.
En fait j'ai viré afp partout, à l'exception d'une platteforme d'échange netatalk+samba / linux parce qu'on a encore du Mac OS 8 et 9. Parce que mêmesur Mac OS X j'ai eu pas mal de problèmes avec l'afp. En fait le seul cas où je pense (j'espère) que l'afp marche bien, c'est avec un système "Mac OS X Server"
-- Nicolas Michel
Nicolas-Michel_REMOVE
Patrick Stadelmann wrote:
In article <1iif6is.1gha1zo1kilv5yN%, (Michel Nicolas Alex) wrote:
pour la stabilité, as-tu testé cifs à la place de smb ?
Ca change quelque chose de se connecter avec cifs:// au lieu de smb:// ?
D'une façon générale cifs est le remplaçant de smb Pendant un temps j'ai cru que c'était du pareil au même, voir que les 2 pointaient sur le même exec.
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
Autre chose, mais j'ai pas constaté le problème presonnellement, suivant les distrib linux on doit utiliser smb ou cifs, l'autre ne fonctionnant pas forcément.
-- Nicolas Michel
Patrick Stadelmann <Patrick.Stadelmann@unine.ch> wrote:
In article
<1iif6is.1gha1zo1kilv5yN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
pour la stabilité, as-tu testé cifs à la place de smb ?
Ca change quelque chose de se connecter avec cifs:// au lieu de smb:// ?
D'une façon générale cifs est le remplaçant de smb
Pendant un temps j'ai cru que c'était du pareil au même,
voir que les 2 pointaient sur le même exec.
Mais finalement ça ne doit pas être le cas parce que ici sur notre
Netapp les tickets kerberos ne sont acceptés que en cifs.
Autre chose, mais j'ai pas constaté le problème presonnellement,
suivant les distrib linux on doit utiliser smb ou cifs, l'autre ne
fonctionnant pas forcément.
In article <1iif6is.1gha1zo1kilv5yN%, (Michel Nicolas Alex) wrote:
pour la stabilité, as-tu testé cifs à la place de smb ?
Ca change quelque chose de se connecter avec cifs:// au lieu de smb:// ?
D'une façon générale cifs est le remplaçant de smb Pendant un temps j'ai cru que c'était du pareil au même, voir que les 2 pointaient sur le même exec.
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
Autre chose, mais j'ai pas constaté le problème presonnellement, suivant les distrib linux on doit utiliser smb ou cifs, l'autre ne fonctionnant pas forcément.
-- Nicolas Michel
laurent.pertois
Michel Nicolas Alex wrote:
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service kerberos qu'autre chose. Mais je peux me tromper.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Mais finalement ça ne doit pas être le cas parce que ici sur notre
Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service
kerberos qu'autre chose. Mais je peux me tromper.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service kerberos qu'autre chose. Mais je peux me tromper.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Nicolas-Michel_REMOVE
Laurent Pertois wrote:
Michel Nicolas Alex wrote:
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service kerberos qu'autre chose. Mais je peux me tromper.
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas t'en dire plus : smb://serveur/share ne prends pas le ticket cifs://serveur/share prends le ticket
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Mais finalement ça ne doit pas être le cas parce que ici sur notre
Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service
kerberos qu'autre chose. Mais je peux me tromper.
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas
t'en dire plus :
smb://serveur/share ne prends pas le ticket
cifs://serveur/share prends le ticket
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service kerberos qu'autre chose. Mais je peux me tromper.
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas t'en dire plus : smb://serveur/share ne prends pas le ticket cifs://serveur/share prends le ticket
-- Nicolas Michel
laurent.pertois
Michel Nicolas Alex wrote:
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas t'en dire plus : smb://serveur/share ne prends pas le ticket cifs://serveur/share prends le ticket
J'ai le même soucis avec Mac OS X Server v10.5.x, le SMB est kerbérisé mais je dois impérativement écrire :
smb://serveur.domaine.tld/share
si j'appelle :
smb://serveur.local/share
ou :
smb://serveur/share
il ne prend pas de ticket vu que ça ne correspond pas au principal du service.
Là où c'est dommage c'est que la navigation par la barre latérale du Finder appelle le nom bonjour.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas
t'en dire plus :
smb://serveur/share ne prends pas le ticket
cifs://serveur/share prends le ticket
J'ai le même soucis avec Mac OS X Server v10.5.x, le SMB est kerbérisé
mais je dois impérativement écrire :
smb://serveur.domaine.tld/share
si j'appelle :
smb://serveur.local/share
ou :
smb://serveur/share
il ne prend pas de ticket vu que ça ne correspond pas au principal du
service.
Là où c'est dommage c'est que la navigation par la barre latérale du
Finder appelle le nom bonjour.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas t'en dire plus : smb://serveur/share ne prends pas le ticket cifs://serveur/share prends le ticket
J'ai le même soucis avec Mac OS X Server v10.5.x, le SMB est kerbérisé mais je dois impérativement écrire :
smb://serveur.domaine.tld/share
si j'appelle :
smb://serveur.local/share
ou :
smb://serveur/share
il ne prend pas de ticket vu que ça ne correspond pas au principal du service.
Là où c'est dommage c'est que la navigation par la barre latérale du Finder appelle le nom bonjour.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Jacques Perrocheau
In article <4850bf9b$0$12001$, "kurtz_le_pirate" wrote:
toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Quel serveur "Windows" ?
"Windows serveur 2000" (Windows NT Services for Macintosh) ?
Si c'est le cas, c'est de l'AppleShare sur AppleTalk, bizarre que cela fonctionne encore pour un client AppleShare sur un Mac OS X 10.4.x ? Il me semble qu'il avait déjà été zappé ne restant que le support pour imprimer en AppleTalk sur les imprimantes Postscript:
PS PostScript (Adobe Systems, Inc.) PAP Printer Access Protocol NBP Name Binding Protocol et ELAP EtherTalk Link Access Protocol
En tous cas si cela existe encore sous Mac OS X 10.4 et 10.5, il faut vérifier que le protocole AppleTalk est activé. Sur Mac OS X 10.4.x, c'est dans "/Applications/Utilities/Directory Access.app". Sur Mac OS X 10.5.x, je ne sais pas.
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
Ils sont "écornés"... ;-)
quelqu'un à les mêmes problème ?
Il ne doit plus avoir grand monde à faire tourner des Win 2K server... !
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <4850bf9b$0$12001$426a34cc@news.free.fr>,
"kurtz_le_pirate" <kurtzlepirate@yahoo.fr> wrote:
toujours suite au passage de tiger à leopard (10.5.2), il
est impossible au utilisateurs de se connecter en 'afp' sur
le serveur windows.
Quel serveur "Windows" ?
"Windows serveur 2000" (Windows NT Services for Macintosh) ?
Si c'est le cas, c'est de l'AppleShare sur AppleTalk, bizarre que cela
fonctionne encore pour un client AppleShare sur un Mac OS X 10.4.x ? Il
me semble qu'il avait déjà été zappé ne restant que le support pour
imprimer en AppleTalk sur les imprimantes Postscript:
PS PostScript (Adobe Systems, Inc.)
PAP Printer Access Protocol
NBP Name Binding Protocol
et
ELAP EtherTalk Link Access Protocol
En tous cas si cela existe encore sous Mac OS X 10.4 et 10.5, il faut
vérifier que le protocole AppleTalk est activé. Sur Mac OS X 10.4.x,
c'est dans "/Applications/Utilities/Directory Access.app". Sur Mac OS X
10.5.x, je ne sais pas.
'smb' permet de se connecter mais les connexions ne sont
pas stable, les fichiers s'abiment,...
Ils sont "écornés"... ;-)
quelqu'un à les mêmes problème ?
Il ne doit plus avoir grand monde à faire tourner des Win 2K server... !
--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <4850bf9b$0$12001$, "kurtz_le_pirate" wrote:
toujours suite au passage de tiger à leopard (10.5.2), il est impossible au utilisateurs de se connecter en 'afp' sur le serveur windows.
Quel serveur "Windows" ?
"Windows serveur 2000" (Windows NT Services for Macintosh) ?
Si c'est le cas, c'est de l'AppleShare sur AppleTalk, bizarre que cela fonctionne encore pour un client AppleShare sur un Mac OS X 10.4.x ? Il me semble qu'il avait déjà été zappé ne restant que le support pour imprimer en AppleTalk sur les imprimantes Postscript:
PS PostScript (Adobe Systems, Inc.) PAP Printer Access Protocol NBP Name Binding Protocol et ELAP EtherTalk Link Access Protocol
En tous cas si cela existe encore sous Mac OS X 10.4 et 10.5, il faut vérifier que le protocole AppleTalk est activé. Sur Mac OS X 10.4.x, c'est dans "/Applications/Utilities/Directory Access.app". Sur Mac OS X 10.5.x, je ne sais pas.
'smb' permet de se connecter mais les connexions ne sont pas stable, les fichiers s'abiment,...
Ils sont "écornés"... ;-)
quelqu'un à les mêmes problème ?
Il ne doit plus avoir grand monde à faire tourner des Win 2K server... !
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
Jacques Perrocheau
In article <1iifipx.oq9ki5g6d2mzN%, (Michel Nicolas Alex) wrote:
Laurent Pertois wrote:
Michel Nicolas Alex wrote:
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service kerberos qu'autre chose. Mais je peux me tromper.
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas t'en dire plus : smb://serveur/share ne prends pas le ticket cifs://serveur/share prends le ticket
Ici un Netapp configuré comment ? je ne sais pas, (authentification adossé à un serveur LDAP, sans cryptage de mot de passe), se moque qu'on lui envoie du cifs ou du smb.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article
<1iifipx.oq9ki5g6d2mzN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
Michel Nicolas Alex <Nicolas-Michel_REMOVE@THIS_bluewin.ch> wrote:
Mais finalement ça ne doit pas être le cas parce que ici sur notre
Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service
kerberos qu'autre chose. Mais je peux me tromper.
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas
t'en dire plus :
smb://serveur/share ne prends pas le ticket
cifs://serveur/share prends le ticket
Ici un Netapp configuré comment ? je ne sais pas, (authentification
adossé à un serveur LDAP, sans cryptage de mot de passe), se moque qu'on
lui envoie du cifs ou du smb.
--
Jacques PERROCHEAU
CNRS UMR 6226
Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
In article <1iifipx.oq9ki5g6d2mzN%, (Michel Nicolas Alex) wrote:
Laurent Pertois wrote:
Michel Nicolas Alex wrote:
Mais finalement ça ne doit pas être le cas parce que ici sur notre Netapp les tickets kerberos ne sont acceptés que en cifs.
M'est avis que c'est surtout une question de nom du principal de service kerberos qu'autre chose. Mais je peux me tromper.
C'est bien possible. N'étant pas admin du dit serveur, je ne peux pas t'en dire plus : smb://serveur/share ne prends pas le ticket cifs://serveur/share prends le ticket
Ici un Netapp configuré comment ? je ne sais pas, (authentification adossé à un serveur LDAP, sans cryptage de mot de passe), se moque qu'on lui envoie du cifs ou du smb.
-- Jacques PERROCHEAU CNRS UMR 6226 Université de Rennes 1, Campus de Beaulieu, 35042 RENNES Cedex, France
