Seen this message: Unable to attach to the given directory
Moderators: chulett, rschirm, roy
Seen this message: Unable to attach to the given directory
This message began appearing on our production server a while back. I've been ignoring it and living with using the command ability in DS Adminstrator. But I really need to get this working again because I do quite a bit of work at the Universe level, especially during promotions.
I've confirmed that the DS Telnet service is running.
I've confirmed that the DS Telnet service is running.
(Well that was pretty silly of me! Sorry, Craig.)
I typically telnet to the server to do most of my Universe level work rather than working through the DS Administrators' Command ability. (I've been working with PICK-like OSs for years and am very comfortable at that level.)
Upon connecting, it prompts for username and password (the same username/password used when connecting to DS) and after entering them, it then returns the message:
This is on a Windows server. I've tried both my personal and my administrator login -- both of which work fine at the DS client login. But both produce this message when I connect via telnet.
If it would simply tell me what directory is missing, maybe I could fix it.
I typically telnet to the server to do most of my Universe level work rather than working through the DS Administrators' Command ability. (I've been working with PICK-like OSs for years and am very comfortable at that level.)
Upon connecting, it prompts for username and password (the same username/password used when connecting to DS) and after entering them, it then returns the message:
Code: Select all
Welcome to the DataStage Telnet Server.
Enter user name: <username>
Enter password:
Unable to attach to the given directory.
DataStage telnet session terminating...
If it would simply tell me what directory is missing, maybe I could fix it.
This message occurs before it even gets to prompting for the project.
The Project folders are all still there and if it was a permissions-related thing then logging into the client and trying to access the project wouldn't work. But I can use the clients fine without any issue.
This seems to be something specific to accessing Universe via telnet.
The Project folders are all still there and if it was a permissions-related thing then logging into the client and trying to access the project wouldn't work. But I can use the clients fine without any issue.
This seems to be something specific to accessing Universe via telnet.
I do not see a DSHOME env variable. I have no additional security installed beyond normal Windows stuff. I administer DataStage on this box and do general administration, and I've not made any changes recently that I could associate with this.
General maintenance (e.g., monthly OS updates, backup scheduling, etc) is handled by our IT group so it is always possible they did something that changed this. But I wouldn't even know what to ask them because they have no clue beyond what they work with.![Confused :?](./images/smilies/icon_confused.gif)
It doesn't appear to be project-specific in that I can't even get to the point of connecting to a project (no project prompt). It is not specific to the username with which I attempt to connect.
I've looked over the permissions and see no exception from what it should be. I've compared the permissions to those on our development system (which is set up almost identically) and the permissions appear to be the same.
To the best of my knowledge (and I work to keep this true), both the prod and dev systems have the same applications installed.
Watching the processes (and comparing between the two servers), I can see tl_dsserver.exe start up when the telnet session begins. The difference is that, after the message appears on production, the tl_dsserver.exe terminates (as one would expect).
I did note that the dev system does not even list the standard MS telnet service while the prod system does list it but it is not started/running.
General maintenance (e.g., monthly OS updates, backup scheduling, etc) is handled by our IT group so it is always possible they did something that changed this. But I wouldn't even know what to ask them because they have no clue beyond what they work with.
![Confused :?](./images/smilies/icon_confused.gif)
It doesn't appear to be project-specific in that I can't even get to the point of connecting to a project (no project prompt). It is not specific to the username with which I attempt to connect.
I've looked over the permissions and see no exception from what it should be. I've compared the permissions to those on our development system (which is set up almost identically) and the permissions appear to be the same.
To the best of my knowledge (and I work to keep this true), both the prod and dev systems have the same applications installed.
Watching the processes (and comparing between the two servers), I can see tl_dsserver.exe start up when the telnet session begins. The difference is that, after the message appears on production, the tl_dsserver.exe terminates (as one would expect).
I did note that the dev system does not even list the standard MS telnet service while the prod system does list it but it is not started/running.
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
An attempt to "telnet <hostname> 2300" failed with the "Could not open connection..." message. I don't think the port is the issue since it is prompting for username/password. I believe that it is only after the port is obtained that it prompts for credentials.
It is clearly accepting the credentials; i.e., no "invalid domain/user/password" message appears. It is only after this point that it tries to switch to some directory and says it cannot attach to "the given directory".
Now, if I can only determine what the "given" directory is I might be able to figure out what it is missing.
It is clearly accepting the credentials; i.e., no "invalid domain/user/password" message appears. It is only after this point that it tries to switch to some directory and says it cannot attach to "the given directory".
Now, if I can only determine what the "given" directory is I might be able to figure out what it is missing.