Dans une architecture SAS© BI (Business Intelligence) distribuée, il est fréquent que le serveur de calcul (Compute Server) soit situé sur une machine différente de celle où résident les données physiques.
Un scénario classique : votre plateforme SAS© est installée sur le Serveur A, mais vous tentez de déclarer une bibliothèque (library) pointant vers des fichiers situés sur le Serveur B. C'est alors que survient le message d'erreur bloquant :
Ce message est particulièrement frustrant car, souvent, l'utilisateur constate qu'il peut accéder au dossier distant via l'explorateur de fichiers Windows (commande "Exécuter") sans problème. Si l'accès système semble fonctionner, pourquoi SAS© refuse-t-il la connexion ?
Voici les pistes de diagnostic et les solutions pour résoudre ce conflit d'autorisation.
C'est la cause la plus fréquente et la plus simple à vérifier.
Par défaut, lorsque SAS© alloue une bibliothèque (via une instruction LIBNAME ou via les métadonnées), il tente souvent d'obtenir un accès complet (Lecture et Écriture).
Si, au niveau du système d'exploitation (Windows/Linux), l'utilisateur ne dispose que de droits en lecture seule sur le dossier partagé du Serveur B, SAS© renverra cette erreur d'autorisation générique, même si vous ne cherchez qu'à lire les données.
La solution : Vérifiez si l'option "Read-Only" est cochée dans les propriétés de la bibliothèque ou forcez l'accès en lecture seule dans votre code (ACCESS=READONLY).
Pour savoir si le blocage vient des métadonnées SAS© ou des permissions système (OS), il existe un test infaillible.
Exécutez manuellement une instruction LIBNAME dans un programme (via SAS© Enterprise Guide ou Studio), en pointant directement vers le chemin réseau, sans passer par la définition des métadonnées pré-enregistrées.
| 1 | LIBNAME TestLib '\\ServeurB\Chemin\Vers\Donnees'; |
Si ce code fonctionne : Cela signifie que les permissions système (OS) sont correctes. Le problème se situe donc dans la définition des métadonnées (SAS© Management Console). Il faut vérifier les permissions sur l'objet bibliothèque dans l'arbre des métadonnées (droits de lecture sur les métadonnées ET sur les données physiques).
Si ce code échoue : Le problème est bien au niveau du système d'exploitation ou du réseau. Le compte utilisateur sous lequel le processus SAS© s'exécute sur le Serveur A n'a pas les droits adéquats sur le Serveur B.
Dans une architecture BI, l'identité de l'utilisateur qui se connecte au portail n'est pas toujours celle qui est utilisée par le serveur pour accéder aux fichiers.
Il est impératif de vérifier la configuration dans la SAS© Management Console :
Ouvrez le User Manager (Gestionnaire d'utilisateurs).
Localisez le profil de l'utilisateur ou du groupe concerné.
Vérifiez l'onglet "Accounts" (Comptes).
Assurez-vous que les identifiants (Login) définis ici correspondent bien à un compte de domaine valide qui possède les privilèges nécessaires sur le serveur distant. Si l'authentification se fait via un compte de service générique (ex: sassrv), c'est ce compte spécifique qui doit avoir les droits sur le dossier partagé, et non votre compte personnel.
L'erreur "Appropriate authorization level" est souvent un masque pour un simple conflit de droits "Lecture vs Écriture" ou une confusion entre l'identité de l'utilisateur connecté et l'identité du processus serveur SAS©. En testant l'accès par code pur, vous isolerez rapidement la couche responsable du blocage.
Die auf WeAreCAS.eu bereitgestellten Codes und Beispiele dienen Lehrzwecken. Es ist zwingend erforderlich, sie nicht blind in Ihre Produktionsumgebungen zu kopieren. Der beste Ansatz besteht darin, die Logik zu verstehen, bevor sie angewendet wird. Wir empfehlen dringend, diese Skripte in einer Testumgebung (Sandbox/Dev) zu testen. WeAreCAS übernimmt keine Verantwortung für mögliche Auswirkungen oder Datenverluste auf Ihren Systemen.