Erreur 70 n'apparaissant que sur certains comptes utilisateurs

gerbito
Messages postés
40
Date d'inscription
mardi 14 décembre 2004
Statut
Membre
Dernière intervention
20 octobre 2015
- 19 oct. 2015 à 16:03
ucfoutu
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
- 20 oct. 2015 à 17:26
Bonjour,

Voilà, j'ai un petit problème avec une appli écrite en VB6 qui doit tourner sur des postes équipés de Windows 7.
Le problème se manifeste sur un poste en particulier
(le seul, elle tourne très bien sur les autres postes pour tous les comptes) :

Lorsque je la lance sur ce poste sous compte administrateur, tout se passe bien, pas de problème, comme sur les autres postes

Mais dès que je la lance sous un compte utilisateur lambda, j'ai ce message :
'Erreur 70, Permission refusée'

Il me faut pouvoir lancer cette appli sur ce poste qui pose problème depuis un compte utilisateur lambda (sans droits admin),
et je ne peux pas modifier le code de cette application.

J'ai déjà essayé :
-Par dcomcnfg.exe, aucun résultat
-En mettant la séurité des applis la plus permissive possible, aucun résultat
-En mettant l'exécution sous mode de compatibilité XP, aucun résultat

N'y aurait-il pas une bidouille à faire dans le paramétrage en l'ordi pour faire
en sorte que cette erreur ne se manifeste plus ?

N'est-il pas possible de désactiver totalement le contrôle de sécurité des applications, vu que c'est lui qui pose problème ?

8 réponses

ucfoutu
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
237
19 oct. 2015 à 17:32
Bonjour,
N'y aurait-il pas une bidouille à faire dans le paramétrage en l'ordi pour faire
en sorte que cette erreur ne se manifeste plus ?

Aucune "bidouille" sans l'intervention de l'un des administrateurs. Sinon, ce ne serait plus de la sécurité
N'est-il pas possible de désactiver totalement le contrôle de sécurité des applications, vu que c'est lui qui pose problème ?

Bien évidemment, mais là encore : intervention de l'un des administrateurs indispensable.
Et c'est heureux, non ?
0
gerbito
Messages postés
40
Date d'inscription
mardi 14 décembre 2004
Statut
Membre
Dernière intervention
20 octobre 2015

20 oct. 2015 à 08:09
Bonjour,

et merci pour votre réponse, bien qu'elle ne m'avance pas beaucoup.

Ce qui m'avancerait, ce serait de savoir comment effectuer cette bidouille qui fera en sorte que cette erreur ne se manifeste plus, et comment désactiver ce contrôle de sécurité des applications.

L'administrateur, il n'y en a pas et il faut que cette appli fonctionne sur le poste en question avec un compte utilisateur, sachant qu'elle fonctionne ainsi sur les autres postes.

Et non, ce n'est pas heureux du tout qu'une soi-disant "sécurité" bloque le fonctionnement de l'appli sur ce poste !
0
NHenry
Messages postés
14995
Date d'inscription
vendredi 14 mars 2003
Statut
Modérateur
Dernière intervention
20 septembre 2022
158
19 oct. 2015 à 17:59
Tu as cette erreur en faisant quelle action ?
As-tu essayé de contrôler l'erreur en utilisant ON ERROR ?
0
gerbito
Messages postés
40
Date d'inscription
mardi 14 décembre 2004
Statut
Membre
Dernière intervention
20 octobre 2015

Modifié par gerbito le 20/10/2015 à 08:22
Bonjour,

et merci pour ta réponse.

Malheureusement, l'exécutable de l'appli ne peut être modifié...

Par contre, je sais quel code est exécuté et pose problème, mais je ne peux le modifier. C'est la sécurité paramétrée sur ce poste qui met le foutoir lors d'une copie de fichier depuis un dossier réseau effectuée au lancement de l'appli. Voici ce qui pose problème :


Dim fs

Set fs = CreateObject("Scripting.FileSystemObject")
fs.CopyFile "[Dossier réseau]\mabase.mdb", App.Path & "\mabase.mdb"



Le problème ne vient de toutes façons pas du code exécuté (qui est correct), mais bien de la sécurité. Quand j'essaie, sur ce poste et sous compte utilisateur, de faire la copie manuellement par l'explorateur Windows, j'ai aussi l'erreur 70 "Permission refusée".
0
NHenry
Messages postés
14995
Date d'inscription
vendredi 14 mars 2003
Statut
Modérateur
Dernière intervention
20 septembre 2022
158
20 oct. 2015 à 12:36
Tu ne pourras pas apsser outre la sécurité du poste.
Donc, utilises ON ERROR pour gérer l'erreur.
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
gerbito
Messages postés
40
Date d'inscription
mardi 14 décembre 2004
Statut
Membre
Dernière intervention
20 octobre 2015

20 oct. 2015 à 13:25
Non...

Car je ne peux pas modifier ce code.
Y compris pour y rajouter ON ERROR. Je ne peux pas gérer l'erreur dans le code, il me faut trouver un moyen de faire en sorte que ce code, que je ne peux modifier, fonctionne sur ce poste dont la sécurité pose problème de la même façon que sur les autres postes.

Il doit être possible de court-circuiter la sécurité sur ce poste, vu que l'appli fonctionne très bien sur les autres postes.

C'est juste sur un poste en particulier que se produit l'erreur 70.
0
ucfoutu
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
237
Modifié par ucfoutu le 20/10/2015 à 15:11
Une autre fois, donc :
- s'il s'agit d'une protection de la machine cliente, tu ne pourras rien faire depuis ton application (me relire)
J'ajoute ceci, par ailleurs :
- certaines machines (dont la mienne, où j'ai carrément inhibé VBS ****) ne laisseraient tout simplement pas passer FSO ! Je ne le dirais jamais assez fort : E V I T E R ce faux-ami FSO
. VB6 offre mieux et moins lourdaud que FSO ! FileCopy existe sous VB6 seul, quand-même !!!! Pourquoi utiliser FSO ??????
- qu'est donc le chemin de App.Path ? Si dossier ou répertoire protégé, ma foi ... tu peux toujours "courir" pour tenter de "bidouiller" ......
        • De nombreux responsables (dont moi-même) ont délibérément inhibé l'exécution de scripts, dont les scripts VBS. Nous avons NOS raisons, que tu comprennes ou non ces raisons. Et dans un tel contexte, aucun de ces scripts ne pourra être exécuté.

-

________________________
Nul ne saurait valablement coder ce qu'il ne saurait exposer clairement.
0
gerbito
Messages postés
40
Date d'inscription
mardi 14 décembre 2004
Statut
Membre
Dernière intervention
20 octobre 2015

Modifié par gerbito le 20/10/2015 à 15:59
Je sais très bien que je ne peux rien faire depuis l'appli, étant donné que je ne peux pas modifier le code de cette appli (me relire aussi... ;) ), je ne peux que voir le code qui est exécuté.

Et ce code, malheureusement, ne comporte pas de gestion d'erreur mais fait appel au FSO. Alors je sais, c'est très moche...

Mais c'est comme ça et cette appli doit fonctionner sur le poste ou elle bloque à cause de la sécurité du poste en question. Parce qu'elle fonctionne très bien sur les autres postes et doit fonctionner aussi sur celui-là.

Si je pouvais régler le problème par le code, il serait réglé depuis longtemps, mais la seule façon de le régler c'est d'influer sur la config du poste. Cela dit, étant donné que l'appli tourne sur tous les autres postes mais pas sur ce poste X, la logique amène à conclure que c'est bien le poste X qui a un problème et pas l'appli.

App.Path, c'est une propriété donnant le chemin de l'exécutable de l'appli, qui se trouve dans un dossier dédié sur "C:\Program Files", que ce soit sur le poste où elle bloque où sur les autres postes où elle se lance sans souci.

Maintenant, pour ce qui est des "responsables" qui font du blocage délibéré, la solution est simple : petit courriel à qui de droit pour signaler que le travail attendu ne peut être réalisé à cause du "responsable" en question, le problème se débloque très très très vite...

Mais là, ce n'est plus le problème, le problème c'est de faire fonctionner cette appli sur ce poste rebelle.
0
ucfoutu
Messages postés
18038
Date d'inscription
lundi 7 décembre 2009
Statut
Modérateur
Dernière intervention
11 avril 2018
237
20 oct. 2015 à 17:26
Désolé, mais je ne vois dans ce cas pas d'autre solution que celle d'intervention "en tant qu'administrateur" du responsable de la machine concernée. Et cet aspect-là ne relève absolument pas du développement sous VB6 (vocation de ce forum).
Quant à :
App.Path, c'est une propriété donnant le chemin de l'exécutable de l'appli, qui se trouve dans un dossier dédié sur "C:\Program Files"

Il se trouve qu'il s'agit-là d'un dossier nativement protégé à partir de Windows 7. Et seul un administrateur, agissant "en tant qu'administrateur", peut lever, s'il y consent, cette protection. C'est à lui (et à lui seul) qu'il appartient de décider de l'opportunité ou non de lever cette protection-là.
Rien d'autre à dire à ce sujet.
0