hi all,
Please be noted that we have installed new window 2008 server but when we try to access the Dynamics Nav 5.0 (SP1), it gives the error, "The operating system cannot gain access to the file "F:\database.fdb", please check that the file type and attribute are correct".
Configuration is as follows :--
1. C:\ Drive : Windows 2008 operating system.
2. D:\ Drive : Dynamics 5.0 (SP1) server & Client installation files.
3. F:\ Drive : "database.fdb"
We are presently using RAID 5 IBM server.
Please suggest.
Hi,
This is window permissions to the fdb file. Right click and select the properties, then change the windows security
Dave Treanor
Dynamics Nav Add-onswww.simplydynamics.ie/Addons.html
Please:1. Use a meaningful title.2. Give as much detail as possible.3."Verify Solution" to the post that help you solve your problem.4. Fill out your Tags - it will help other people.5. N.B. Don't be afraid to ask - we all had to learn and are still learning
What was the source of the *.fdb file? If it came from a read-only source (CD/DVD) it may be flagged as a read-only file. Look at the file properties (right-click) and remove the attribute.
Question:
If you are using a NAV server why would you be accessing the *.fdb from the client? Or are you getting this error when attemping to connect to the server?
Hi
Just Check & untick the read only permission on the properties (Right click on FDB File)
Ashish Bhardwaj
Extremely thankful to all. Actually it was window permissions to the fdb file. As per you people suggestion I right click the Database file and selected the properties, and changed the windows "security/permission" of "ERP/Users".
Thanks again
Glad to Help
I'm a bit confused here. Is this running as a server (multi-user) or single user. If running as multi-user, the users do not need permisisons to the *.fdb file. Only the account running the server service does.
Yes it is confusing and I have encounter this a number of times. The database service starts fine and when you go to connect from a client through the database service you get the error. It normally occurs when you copy in a database from another place e.g. the user test database. You would think that the database service would give the error when it is started again but no. Changing the serurity was the way around it that I found.
I'm not confused by the process. I'm confused by this thread. Are we talking single-user or multi-user. In multi-user (server) only the user account that is running the service needs rights to the database files. In fact, users should have no rights whatsoever to the server on which the database is running. Users only need to communicate with the service. They do not need to access the data file.
This sounds like you are dealing with an inherited permissions issue. Under certain situations (I can't recall them right now) a copied file inherits the permission settings of the source directory. If the service user did not have access to the file in its original directory it may not have them when you move the file. But it's the service user that would be the issue.
babrown:In fact, users should have no rights whatsoever to the server on which the database is running. Users only need to communicate with the service. They do not need to access the data file.
Stelco`s question is rather unconcrete - theoretically, if user(s) have rights to the server AND they try to access the DB directly, which is already opened by service, thus keeping the DB file "open", such user(s) can get the message "The operating system cannot gain access...
Question still remains - was this the case, and, for what sake someone would try to fulfill something like the purely theoretical scenario above :)
Modris Ivans MCP-Dynamics NAV ApplicationPlease specify in your posts1.product and DB version;2.locale, or use International Forums"Verify Solution" to post that helped you solve your problem
Modris Ivans: babrown:In fact, users should have no rights whatsoever to the server on which the database is running. Users only need to communicate with the service. They do not need to access the data file. Stelco`s question is rather unconcrete - theoretically, if user(s) have rights to the server AND they try to access the DB directly, which is already opened by service, thus keeping the DB file "open", such user(s) can get the message "The operating system cannot gain access... Question still remains - was this the case, and, for what sake someone would try to fulfill something like the purely theoretical scenario above :)
This is a good example of why you don't give users file access rights to the data handled by database servers. A good argument for dedicated database servers. But even if they are not dedicated the data files should be in a folder(s) that users do not have acces to.
babrown: seems we are going offtopic - but I have seen SO much practically unadministered networks, that nothing suprises me, especially, when advanced users come into play... recently there was a thread about problem, when someone started to delete unwanted records from SQL base thru SQL Enterprise manager and asked why his NAV crashed and how to cure it afterwards...
I have 16+ years of network integration experience from my last job. I could tell you some real horror stories.
babrown: I'm not confused by the process. I'm confused by this thread. Are we talking single-user or multi-user. In multi-user (server) only the user account that is running the service needs rights to the database files. In fact, users should have no rights whatsoever to the server on which the database is running. Users only need to communicate with the service. They do not need to access the data file.
To me, the tread was multi-user and the security was the issue. The normal confusion is that the service is run as the Administrator of the server and the database file has permissions on the Administrator of the domain.