Soyons le plus claire possible, car le problème n'est pas simple.
Je dispose d'un serveur NIS et NFS.
Cela donne la possibilité à chaque utilisateurs de se connecter sur
n'importe quel poste et d'obtenir sa "Home". J'utilise pour ca un
automonteur. Le serveur NIS et NFS ne comporte pas de serveur X.
Chaque poste client utilise KDE. La connexion pour les utilisateurs ne
posent aucun problème et les applications qu'ils utilisent se lance
correctement excepté Totem.
Lors du lancement de Totem, j'obtiens l'alerte suivante :
WARNING **: Failed to lock: No locks available
L'application se ferme par la suite.
Je suposse que le problème vient à la création de la socket par Totem
dans la "home" de l'utilisateur. La "home" n'appartenant pas au poste
qui exécute Totem, il y a une erreur.
Mais comment faire alors pour exécuter Totem dans cette configuration ?
Je tiens à signaler qu'il n'y a aucun problème dans l'exécution de Totem
sur un poste dont l'utilisateur est de type "local" (compte configuré en
local sur le poste client).
J'ai placé l'option "no_root_squash" pour le montage nsf des "home" des
utilisateurs. L'utilisateur root du client dispose ainsi des permissions
de l'utilisateur root du serveur nfs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Philippe Delsol
Bonjour,
Bonsoir,
Soyons le plus claire possible, car le problème n'est pas simple.
Je dispose d'un serveur NIS et NFS. Cela donne la possibilité à chaque utilisateurs de se connecter sur n'importe quel poste et d'obtenir sa "Home". J'utilise pour ca un automonteur. Le serveur NIS et NFS ne comporte pas de serveur X.
Chaque poste client utilise KDE. La connexion pour les utilisateurs ne posent aucun problème et les applications qu'ils utilisent se lance correctement excepté Totem.
Lors du lancement de Totem, j'obtiens l'alerte suivante : WARNING **: Failed to lock: No locks available
Pouver vous faire le test suivant : dans une console de l'utilisateur entrer la commande
strace -o totem.trc totem
Cela va créer le fichier totem.trc dans lequel il y a l'ensemble des "appels système" de totem avec leur code retour. Vous devez pouvoir y repérer à quel endroit ça plante et peut être pourquoi (regarder vers la fin du fichier, il est en général assez volumineux sauf si ça plante rapidement). Pour filter strace voir le man.
L'application se ferme par la suite.
Je suposse que le problème vient à la création de la socket par Totem dans la "home" de l'utilisateur. La "home" n'appartenant pas au poste qui exécute Totem, il y a une erreur.
Mais comment faire alors pour exécuter Totem dans cette configuration ?
Je tiens à signaler qu'il n'y a aucun problème dans l'exécution de Totem sur un poste dont l'utilisateur est de type "local" (compte configuré en local sur le poste client). J'ai placé l'option "no_root_squash" pour le montage nsf des "home" des utilisateurs. L'utilisateur root du client dispose ainsi des permissions de l'utilisateur root du serveur nfs.
Bruno
Philippe
Bonjour,
Bonsoir,
Soyons le plus claire possible, car le problème n'est pas simple.
Je dispose d'un serveur NIS et NFS.
Cela donne la possibilité à chaque utilisateurs de se connecter sur
n'importe quel poste et d'obtenir sa "Home". J'utilise pour ca un
automonteur. Le serveur NIS et NFS ne comporte pas de serveur X.
Chaque poste client utilise KDE. La connexion pour les utilisateurs ne
posent aucun problème et les applications qu'ils utilisent se lance
correctement excepté Totem.
Lors du lancement de Totem, j'obtiens l'alerte suivante :
WARNING **: Failed to lock: No locks available
Pouver vous faire le test suivant :
dans une console de l'utilisateur entrer la commande
strace -o totem.trc totem
Cela va créer le fichier totem.trc dans lequel il y a l'ensemble des
"appels système" de totem avec leur code retour. Vous devez pouvoir y
repérer à quel endroit ça plante et peut être pourquoi (regarder vers la
fin du fichier, il est en général assez volumineux sauf si ça plante
rapidement).
Pour filter strace voir le man.
L'application se ferme par la suite.
Je suposse que le problème vient à la création de la socket par Totem
dans la "home" de l'utilisateur. La "home" n'appartenant pas au poste
qui exécute Totem, il y a une erreur.
Mais comment faire alors pour exécuter Totem dans cette configuration ?
Je tiens à signaler qu'il n'y a aucun problème dans l'exécution de Totem
sur un poste dont l'utilisateur est de type "local" (compte configuré en
local sur le poste client).
J'ai placé l'option "no_root_squash" pour le montage nsf des "home" des
utilisateurs. L'utilisateur root du client dispose ainsi des permissions
de l'utilisateur root du serveur nfs.
Soyons le plus claire possible, car le problème n'est pas simple.
Je dispose d'un serveur NIS et NFS. Cela donne la possibilité à chaque utilisateurs de se connecter sur n'importe quel poste et d'obtenir sa "Home". J'utilise pour ca un automonteur. Le serveur NIS et NFS ne comporte pas de serveur X.
Chaque poste client utilise KDE. La connexion pour les utilisateurs ne posent aucun problème et les applications qu'ils utilisent se lance correctement excepté Totem.
Lors du lancement de Totem, j'obtiens l'alerte suivante : WARNING **: Failed to lock: No locks available
Pouver vous faire le test suivant : dans une console de l'utilisateur entrer la commande
strace -o totem.trc totem
Cela va créer le fichier totem.trc dans lequel il y a l'ensemble des "appels système" de totem avec leur code retour. Vous devez pouvoir y repérer à quel endroit ça plante et peut être pourquoi (regarder vers la fin du fichier, il est en général assez volumineux sauf si ça plante rapidement). Pour filter strace voir le man.
L'application se ferme par la suite.
Je suposse que le problème vient à la création de la socket par Totem dans la "home" de l'utilisateur. La "home" n'appartenant pas au poste qui exécute Totem, il y a une erreur.
Mais comment faire alors pour exécuter Totem dans cette configuration ?
Je tiens à signaler qu'il n'y a aucun problème dans l'exécution de Totem sur un poste dont l'utilisateur est de type "local" (compte configuré en local sur le poste client). J'ai placé l'option "no_root_squash" pour le montage nsf des "home" des utilisateurs. L'utilisateur root du client dispose ainsi des permissions de l'utilisateur root du serveur nfs.
Bruno
Philippe
Bruno Philippe
J'ai effectué la trace depuis un compte local et un compte distant.
Depuis un compte distant lors de la création de la socket il y a l'erreur suivante :
Bon maintenant je sèche completement. Si quelqu'un à une idée ?
Bonjour,
Bonsoir,
Soyons le plus claire possible, car le problème n'est pas simple.
Je dispose d'un serveur NIS et NFS. Cela donne la possibilité à chaque utilisateurs de se connecter sur n'importe quel poste et d'obtenir sa "Home". J'utilise pour ca un automonteur. Le serveur NIS et NFS ne comporte pas de serveur X.
Chaque poste client utilise KDE. La connexion pour les utilisateurs ne posent aucun problème et les applications qu'ils utilisent se lance correctement excepté Totem.
Lors du lancement de Totem, j'obtiens l'alerte suivante : WARNING **: Failed to lock: No locks available
Pouver vous faire le test suivant : dans une console de l'utilisateur entrer la commande
strace -o totem.trc totem
Cela va créer le fichier totem.trc dans lequel il y a l'ensemble des "appels système" de totem avec leur code retour. Vous devez pouvoir y repérer à quel endroit ça plante et peut être pourquoi (regarder vers la fin du fichier, il est en général assez volumineux sauf si ça plante rapidement). Pour filter strace voir le man.
L'application se ferme par la suite.
Je suposse que le problème vient à la création de la socket par Totem dans la "home" de l'utilisateur. La "home" n'appartenant pas au poste qui exécute Totem, il y a une erreur.
Mais comment faire alors pour exécuter Totem dans cette configuration ?
Je tiens à signaler qu'il n'y a aucun problème dans l'exécution de Totem sur un poste dont l'utilisateur est de type "local" (compte configuré en local sur le poste client). J'ai placé l'option "no_root_squash" pour le montage nsf des "home" des utilisateurs. L'utilisateur root du client dispose ainsi des permissions de l'utilisateur root du serveur nfs.
Bruno
Philippe
J'ai effectué la trace depuis un compte local et un compte distant.
Depuis un compte distant lors de la création de la socket il y a
l'erreur suivante :
Bon maintenant je sèche completement. Si quelqu'un à une idée ?
Bonjour,
Bonsoir,
Soyons le plus claire possible, car le problème n'est pas simple.
Je dispose d'un serveur NIS et NFS.
Cela donne la possibilité à chaque utilisateurs de se connecter sur
n'importe quel poste et d'obtenir sa "Home". J'utilise pour ca un
automonteur. Le serveur NIS et NFS ne comporte pas de serveur X.
Chaque poste client utilise KDE. La connexion pour les utilisateurs ne
posent aucun problème et les applications qu'ils utilisent se lance
correctement excepté Totem.
Lors du lancement de Totem, j'obtiens l'alerte suivante :
WARNING **: Failed to lock: No locks available
Pouver vous faire le test suivant :
dans une console de l'utilisateur entrer la commande
strace -o totem.trc totem
Cela va créer le fichier totem.trc dans lequel il y a l'ensemble des
"appels système" de totem avec leur code retour. Vous devez pouvoir y
repérer à quel endroit ça plante et peut être pourquoi (regarder vers la
fin du fichier, il est en général assez volumineux sauf si ça plante
rapidement).
Pour filter strace voir le man.
L'application se ferme par la suite.
Je suposse que le problème vient à la création de la socket par Totem
dans la "home" de l'utilisateur. La "home" n'appartenant pas au poste
qui exécute Totem, il y a une erreur.
Mais comment faire alors pour exécuter Totem dans cette configuration ?
Je tiens à signaler qu'il n'y a aucun problème dans l'exécution de
Totem sur un poste dont l'utilisateur est de type "local" (compte
configuré en local sur le poste client).
J'ai placé l'option "no_root_squash" pour le montage nsf des "home"
des utilisateurs. L'utilisateur root du client dispose ainsi des
permissions de l'utilisateur root du serveur nfs.
Bon maintenant je sèche completement. Si quelqu'un à une idée ?
Bonjour,
Bonsoir,
Soyons le plus claire possible, car le problème n'est pas simple.
Je dispose d'un serveur NIS et NFS. Cela donne la possibilité à chaque utilisateurs de se connecter sur n'importe quel poste et d'obtenir sa "Home". J'utilise pour ca un automonteur. Le serveur NIS et NFS ne comporte pas de serveur X.
Chaque poste client utilise KDE. La connexion pour les utilisateurs ne posent aucun problème et les applications qu'ils utilisent se lance correctement excepté Totem.
Lors du lancement de Totem, j'obtiens l'alerte suivante : WARNING **: Failed to lock: No locks available
Pouver vous faire le test suivant : dans une console de l'utilisateur entrer la commande
strace -o totem.trc totem
Cela va créer le fichier totem.trc dans lequel il y a l'ensemble des "appels système" de totem avec leur code retour. Vous devez pouvoir y repérer à quel endroit ça plante et peut être pourquoi (regarder vers la fin du fichier, il est en général assez volumineux sauf si ça plante rapidement). Pour filter strace voir le man.
L'application se ferme par la suite.
Je suposse que le problème vient à la création de la socket par Totem dans la "home" de l'utilisateur. La "home" n'appartenant pas au poste qui exécute Totem, il y a une erreur.
Mais comment faire alors pour exécuter Totem dans cette configuration ?
Je tiens à signaler qu'il n'y a aucun problème dans l'exécution de Totem sur un poste dont l'utilisateur est de type "local" (compte configuré en local sur le poste client). J'ai placé l'option "no_root_squash" pour le montage nsf des "home" des utilisateurs. L'utilisateur root du client dispose ainsi des permissions de l'utilisateur root du serveur nfs.
Bruno
Philippe
Philippe Delsol
J'ai effectué la trace depuis un compte local et un compte distant.
Depuis un compte distant lors de la création de la socket il y a l'erreur suivante :
Non, cette erreur ne correspond pas au plantage. On a la même quand on execute en local mais elle n'a pas d'incidence.
Par la suite quand, le programme tente de se connecter à la socket on obtient :
socket(PF_UNIX, SOCK_STREAM, 0) = 13 fcntl64(13, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 connect(13, {sa_family¯_UNIX, path="/home/jacques/tmp/orbit-jacques/linc-fe9-0-7ad567bf2e7"}, 53) = -1 ENOENT (No such file or directory)
Par contre c'est bien ici qu'il y a le problème. Première vérification : est ce que le répertoire /home/jacques/tmp/orbit-jacques existe ? Quels en sont les droits lecture/écriture. Est ce que l'utilisateur peut faire un "touch /home/jacques/tmp/orbit-jacques/un_fichier_test" ? D'aprés ce que j'ai pu comprendre ce répertoire est de type nfs et "automounté" ? Quels sont les droits d'exportation coté nfs serveur ?
En local aucun problème lors de la de la socket.
En fait les paramètres suivant n'existent pas : {sa_family¯_INET, sin_port=htons(917), sin_addr=inet_addr("0.0.0.0")}
Non, cette erreur ne correspond pas au plantage.
On a la même quand on execute en local mais elle n'a pas d'incidence.
Par la suite quand, le programme tente de se connecter à la socket on
obtient :
socket(PF_UNIX, SOCK_STREAM, 0) = 13
fcntl64(13, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
fcntl64(13, F_SETFD, FD_CLOEXEC) = 0
connect(13, {sa_family¯_UNIX,
path="/home/jacques/tmp/orbit-jacques/linc-fe9-0-7ad567bf2e7"}, 53) = -1
ENOENT (No such file or directory)
Par contre c'est bien ici qu'il y a le problème.
Première vérification : est ce que le répertoire
/home/jacques/tmp/orbit-jacques existe ? Quels en sont les droits
lecture/écriture.
Est ce que l'utilisateur peut faire un
"touch /home/jacques/tmp/orbit-jacques/un_fichier_test" ?
D'aprés ce que j'ai pu comprendre ce répertoire est de type nfs et
"automounté" ?
Quels sont les droits d'exportation coté nfs serveur ?
En local aucun problème lors de la de la socket.
En fait les paramètres suivant n'existent pas : {sa_family¯_INET,
sin_port=htons(917), sin_addr=inet_addr("0.0.0.0")}
Non, cette erreur ne correspond pas au plantage. On a la même quand on execute en local mais elle n'a pas d'incidence.
Par la suite quand, le programme tente de se connecter à la socket on obtient :
socket(PF_UNIX, SOCK_STREAM, 0) = 13 fcntl64(13, F_SETFL, O_RDONLY|O_NONBLOCK) = 0 fcntl64(13, F_SETFD, FD_CLOEXEC) = 0 connect(13, {sa_family¯_UNIX, path="/home/jacques/tmp/orbit-jacques/linc-fe9-0-7ad567bf2e7"}, 53) = -1 ENOENT (No such file or directory)
Par contre c'est bien ici qu'il y a le problème. Première vérification : est ce que le répertoire /home/jacques/tmp/orbit-jacques existe ? Quels en sont les droits lecture/écriture. Est ce que l'utilisateur peut faire un "touch /home/jacques/tmp/orbit-jacques/un_fichier_test" ? D'aprés ce que j'ai pu comprendre ce répertoire est de type nfs et "automounté" ? Quels sont les droits d'exportation coté nfs serveur ?
En local aucun problème lors de la de la socket.
En fait les paramètres suivant n'existent pas : {sa_family¯_INET, sin_port=htons(917), sin_addr=inet_addr("0.0.0.0")}
