System Admins... Help!

[ifall 0]

I cannot wrap my head around this problem I am having. I have a new server I'm trying to migrate two databases over to because the server they are on had a perc controller failure and is on it's last limb. I can do anything on the server when RDP'd into it because I am a domain administrator. However after I got the databases moved and added the user group's permissions I UNC into the folders and I cannot add sub-folders write to folders etc. even as a domain admin. Users need to be able to read/write to these folders, obviously, so they are not able to get into the programs I migrated.

I have made sure there was not a maximum # of users set on the shared folders, made sure domain admins and even my username was in the local administrator's group and still cannot do anything within those folders. I tried taking ownership of the folders within remote console and still cannot do anything. I have also mapped a local drive to the folders and get the same results. Another thing I just got done trying is taking the server off the domain, rebooting and putting the server back on the domain. I'm running out of ideas and have never had this problem before.

So, to sum it up, I have full admin rights to these folders and the drives they are on, I can do anything within them when I RDP into the server but that is the only way I can do anything within those folders. Any thoughts?

[justinb138 0]

Are the folders that you're trying to share the folders containing the data files for the DB server? I've had Windows do some odd things when trying to change permissions on the folders containing the data files if the databases were online.

[ifall 0]

Yes, if you mean the actual data not the DB engine files. When the program is opened on the client PC that is when the DB engine tries to access those folders, but not when just the DB engine is running. I have the DB engine installed to a separate folder on a separate drive (partition), it does not need to be shared and it is running (Pervasive SQL) for one, the other does not use a DB engine. I think it's something coming from the root drive that the folders are stored in just can't pin it.

Might help if you all knew the OS on the server is Windows Server 2003.

[Bolas 5]

What method did you use to transfer the data?

Do you have an other 2003 x64 boxes you could try this on?

Does this app support x64? If not, you're better off running 32 bit OS.

Stupidity if left untreated is self-correcting
If ya can't be good, look good, if that fails, make 'em laugh.

[ifall 0]

I just copied the data files after creating the folders and installing the DB engine. Tested the DB engine first and it ran fine so then I copied the DB files. This is what the company that developed the software confirmed to do. I also tried restoring the DB files from backup tape to the new folders but that failed too due to authentication error.

Sorry it's not x64, I have x64 Citrix servers that I primarily work on and I accidently put that there.

[Bolas 5]

See if you can repeat the issue on another folder structure, drive, server.

Beat on the vendor too.

Stupidity if left untreated is self-correcting
If ya can't be good, look good, if that fails, make 'em laugh.

[ifall 0]

I'll try a different server tomorrow. I'm really wondering now if it has to do with copying from a 2000 server though. The permissions did not get copied when I did it so I had to set them up on the new server. Set them exactly the same as the old server too.

Funny thing is, the vendor called me today asking if I figured out what the issue is. I get that a LOT when I run into issues with our vendor's software! I've probably contributed quite a bit to our vendor's knowledge bases. Maybe I should start charging them...

[justinb138 0]

I'm really only familiar with SQL Server on 03, but what account does the database server run under?

I've had issues restoring DB files before if the DB Server user account doesn't have permissions in the data folder.

Also, are the folders you're working with set to inherit permissions? If possible, disable that to see if you can change the permissions and get it working, just be sure to make any changes propagate to the child objects when you make them.

[DigitalDave 0]

Are you certain the DB software is not locking the files/directories? Did you copy the directories, or you re made them entirely? Could you make directories prior to installing the DB software?

Although copying raw binary DB files directly will work in most cases, it's usually preferable to dump the data, create the new DB from the schema and source the data in. This is especially true if moving between DB versions, or file systems/OS's etc. You run the risk of transferring corrupt tables otherwise.

It's probably outside the scope of this thread, but allowing users to write to a directory that contains raw DB files is never a good idea.

[ifall 0]

Quote

Are you certain the DB software is not locking the files/directories? Did you copy the directories, or you re made them entirely? Could you make directories prior to installing the DB software?

Positive. The relational and transactional database services have been stopped since Monday. These are just data folders. They are not accessed until a user logs into the software client. I've also copied the directories for the data and created new directories and copied the data from the old server's directories, each way I get the same result.

Quote

Although copying raw binary DB files directly will work in most cases, it's usually preferable to dump the data, create the new DB from the schema and source the data in. This is especially true if moving between DB versions, or file systems/OS's etc. You run the risk of transferring corrupt tables otherwise.

I asked if I should do a dump instead of just copying the files into the shared folder on the new server and the vendor said that it did not matter. Same DB version also, only difference is OS so that is one of my concerns.

Quote

It's probably outside the scope of this thread, but allowing users to write to a directory that contains raw DB files is never a good idea.

Like I said these are just the data files, users need to write to those in order to make updates etc. I'm not a DB guy so we could be on a different page about this here but these are just data files.

As an update. If I include the hidden share drive letter in the UNC I can modify things within that folder. ie. \\server-name\d$\foldername

Don't know why adding the hidden drive (D$) in the UNC or mapped drive makes a difference. I don't have to do that with all my other shared folders.

[Bolas 5]

Check your share permissions.

Were you trying to do this directly on the server through RDP or across the network through the share?

Stupidity if left untreated is self-correcting
If ya can't be good, look good, if that fails, make 'em laugh.

[ifall 0]

I will double check them. I logged off for the night, you got me thinking earlier and I was on for a little bit looking at security but I didn't look at permissions under the actual share tab thinking that was all set by security. I set and change all permissions using RDP. I don't do any of that across the network through the share.

If worse comes to worse I now know that I can get into the registry of the client PC's and set a couple keys to include the hidden share and also map it with the hidden share added but I hate not being able to figure out what is different about these folder's permissions when on the surface they look the same as the folders on the old server.

Thanks for the help all.

[Beachbum 0]

You probably would have caught it already, but worth a check if you didn't ... another thing you might check is to be sure that folder and file names copied with the same case ... I got bit by that once moving stuff to a unix system, when things all copied lower case.

As long as you are happy with yourself ... who cares what the rest of the world thinks?

[ifall 0]

I did make sure all cases were the same. Unix is VERY sensitive to that and I've wasted time figuring out past problems on our Unix server that ended up to be simple case sensitive issues. I did notice that when I copied folders from the old server it copied them as "Copy of on " so I had renamed them all to what they should really be.

[DiverMike 5]

Can you get to the main drive of the share using UNC? For example, if your share is on the D drive of a server named "FILESRV", can you get to \\FILESRV\D$ ? Can you get to \\Filesrv\D$\Sharedfolder\ If so, the problem is definitely in the permissions of your share and not the folder, but you probably already know that.

For the same reason I jump off a perfectly good diving board.

[ifall 0]

Yep, I can do all that. It was a permissions issue. It's working now! I had not thought to look in the permissions within the share and was just doing everything through the security tab. Permissions were just set to read. Thanks for all the replies everyone! Can't believe I overlooked something so simple.