Problem:
About 5 NT workstations reported that once they brought up the log-in for Business Objects and logged is with their user name they got the message:
cannot access local security file
At first we thought this was isolated to only those 5 PCs but now it is affecting a few more machines including our Citrix server.
We are running Business Objects 4.1.1 and we have a Novell environment in that the applications are shared.
We ran into a similar problem about 6 months ago and after reinstalling B.O. we were fine. I don’t really like doing that. Any thoughts?
Do they access the OBJECTS file locally or shared? We had the same problem and BusObj support told me to use the OBJECTS file locally. We also had to copy the objects.lsi file from the server Master installation to the LocData directory on each client PC.
Everything is shared on a network drive. This has been like this for about 2 years now. We actually started with having the objects.lsi file stored locally until B.O. told us that we would not have to do this if we installed B.O. on a network.
“Baranowski, George” GBaranowski@QUADRAMED.COM 03/15/00 12:37PM >>>
Do they access the OBJECTS file locally or shared? We had the same problem and BusObj support told me to use the OBJECTS file locally. We also had to copy the objects.lsi file from the server Master installation to the LocData directory on each client PC.
Maybe a BusObj staffer monitoring this LISTSERV can comment on the right way to do this (or at least on the pros and cons of each approach)? We started with the objects file on the server until BusObj told us to load it locally - just the opposite of your experience.
When I didn’t get any other responses from the listserv. I called B.O. technical support directly. They actually were quick to respond and told me that the OBJECTS.SSI file may be corrupted. After checking that shared file I did notice that the file was last updated the day before. This file actually gets updated as users log-in so I should have had a later datetime stamp on that file. I copied over the original OBJECTS.SSI file from our initial installation of Business Objects and everything ran fine.
thanks again George,
joe
“Baranowski, George” GBaranowski@QUADRAMED.COM 03/15/00 01:19PM >>>
Maybe a BusObj staffer monitoring this LISTSERV can comment on the right way to do this (or at least on the pros and cons of each approach)? We started with the objects file on the server until BusObj told us to load it locally - just the opposite of your experience.
In a message dated 00-03-15 13:23:53 EST, you write:
We started
with the objects file on the server until BusObj told us to load it locally - just the opposite of your experience.
LOL! Sorry, not to poke fun at your problem, but I worked in tech support for a while (a long time ago for a company far, far away…) and this struck me as funny. Something along the lines of…
Tech support call:
Tech: Did you try solution “A”?
Caller: Yes.
Tech: Did it work?
Caller: No
Tech: Try solution “B”.
Caller: Great, it’s fixed! You are a genius!
Next call:
Tech: Did you try solution “B”?
Caller: Yes
Tech: Did it work?
Caller: No
Tech: Try solution “A”
Caller: Great, it’s fixed! You are a genius!
If you are trying to access a master setup from client then make sure u have access to write in Shdata directory of the Master setup.
You may also checkup the setup and see whethere the location of the security files are local or shared. If it is shared then u should have access WRITE permissions on the Master directory and if it is local then u should have write permissions on the Locdata folder of the Client.
Venky.
__________________________________________________ Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/
take that previous step one step further… from the install screen, there is a ‘modify’ button in the lower right, hit that and verify ALL the directory locations…
that is where you will see the shdata, locdata, etc - more importantly, that will show you shared or local…
I checked the install file location using Start/Program Files/BusinessObjects/Setup. The installation folder is c:\Program Files\BusinessObjects. I plan to check whether the user has write access to the file (p. 144 of online BO error message manual). If so, I guess the
next step will be to reinstall BusinessObjects unless anyone has any other ideas.
Thanks for your help.
Brent wrote:
have you checked (thru Setup, off the Business Objects branch of the
Start
Menu) what the file locations are, and if they are ‘shared’ or ‘local’?
you may be set to look for an ssi file, not the lsi… or shdata, not locdata - it’s EASY to do…
Gary wrote:
We are getting this error in 4.1.4 (stand-alone install). I renamed the objects.lsi file to objects.bak. When the user logged in, the same
error
resulted. I then copied the objects.lsi file from a good machine to the folder. The error again occurred when the user logged in. Does anyone know what the problem may be?
The error has gone away today. Nothing has changed other than powering the pc down and upovernight. The user is using my objects.lsi file which did not work yesterday. It is a local installation. Does anyone know what is going on?
i had a case where the client box was attempting to connect to a network drive, even tho it didnt use it (shdata was on the master install disk on an nt box)… the connection got broken, and the user was hosed… maybe?
The error has gone away today. Nothing has changed other than powering the
pc down and upovernight. The user is using my objects.lsi file which did not work yesterday. It is a local installation. Does anyone know what is going on?
We had this same problem in v4.1.4 … It happened every time a users’ password expired (including a new install/user that was required to change their password on first login) … Never really found a solution, the users just got used to it … Regardless, the problem is resolved in v5.0.3
We are getting this error in 4.1.4 (stand-alone install). I renamed the objects.lsi file to objects.bak. When the user logged in, the same error resulted. I then copied the objects.lsi file from a good machine to the folder. The error again occurred when the user logged in. Does anyone know what the problem may be?