Working in Red Hat Linux trying to build RPMs that are accessed via Clearcase vobs but keep on getting a recurring error which states, 'unable to find albd-server on host ', 'Unable to contact view - clearcase object not found' and 'Unknown host - Name or service not know'. Any guidance would be much appreciated.
I solved the issue in the end by using clearmake -V in the makeall script. Because I'm working with shareable DOs this enabled me to avoid winking in between views. Thankfully it built successfully this time but instead of it being in the build error log it appeared as a test failure. Thanks for the help.
Check first the vobrpc_server_log on the ClearCase Vob Server.
As seen in this technote (for an older version of ClearCase, but still relevant)
Attempts to mount a VOB results in the following error:
ClearCase Object Not Found
This error may get reported in the VOBRPC error log:
01/06/2006 09:24:34 vobrpc_server(5016): Error: vobrpc_server.exe(5016):
Error: Unable to get VOB tag registry information for replica uuid
"db7983f9.052d498a.915f.bb:f9:0e:b0:b4:ea":
ClearCase object not found
This error may get reported in the vob_scrubber log:
vob_scrubber: Error: Unable to get VOB tag registry information
for replica uuid "db7983f9.052d498a.915f.bb:f9:0e:b0:b4:ea":
ClearCase object not found
This error will occur when trying to mount the VOB before the VOB tag creation is complete.
This would be due to a timing issue where the cleartool mkvob and cleartool mount operations are done via a script, and maybe a longer pause is required before the VOB is mounted on a remote host.
This would also be true in an environment where the VOB creation takes several moments to complete, and there is an extended period before the VOB tag is available for users to mount.
Note: This does not occur as a result of the cleartool mount that is executed automatically during the cleartool mkvob operation.
Cause 2: The VOB tag may still exist even though the VOB storage (or VOB server host) are no longer available in the ClearCase network.
This will happen as a result of improper removal of the VOB storage.
Cause 3: The server storage location (network share or export) is not available.
When mounting a VOB, the location that the VOB is stored must be accessible from the host that you are trying to mount the VOB.
Cause 4: If the VOB is not yet tagged in the primary region of the VOB server.
This is applicable to environments that have multiple registry regions.
Is this a clearmake build? Does it complete? (Winkin and shopping failures USUALLY don't cause a build failure.) What is printing those errors? Clearmake? Another ClearCase tool?
What is the exact version of ClearCase? If 9.0.1.x, the patch level and your license type may matter, as some older 9.0.1.x releases had an issue where you would get "extra" errors if you had albd contact failures and you use Rational Common Licensing.
Cannot seem to find any concise information on this at all so trying my luck here.
Recently have setup Integration Services Catalogs because at present all our SSIS packages are stored within a folder and just ran as a File. We wish to move these, which has worked fine.
I have created a basic SSIS Package that puts a Username into a SQL Table and then also a File System Task to Delete a File.
When the package is ran from the Catalog via SSMS it completes the SQL side of things perfectly fine, placing both the Username running the package and the data into the SQL table, however it fails on the File System Task with
"File System Task: Error: An error occured with the following error message : "Access to the path "xxxx" is denied.
I have changed the SQL Agent Job on the SQL Server to have the permissions of our Administrator Account with no luck.
I can confirm the folder in question is Shared, it has FULL Read/Write Permission to "Everyone" and yet I still get this error.
I even went to the trouble of creating a new folder and just enabled full sharing to everybody on it - I still get the same access is denied.
Seen a previous post on stackoverflow about NETWORK SERVICE being added, can also confirm that this has full permission to the folder and thus it rules this out also.
Any thoughts would be appreciated.
This is a follow on from op - Moving Vobs between Win and AIX
Due to the aix and win vob servers sharing resources (common CC reg & Common Admin PVOB on the Aix box) we need to amalgamate these vob servers onto the AIX server as a precursor to our ultimate move to new servers at CC8.
on the Win VOb Server we have locked the vob, run vob_siddump then a reformat dump of the vob.
Then using xcopy we copied the dumped vob.vbs from Windows to AIX vob server run the fix_prot on the new server.
But when we run the reformatvob -load it goes through it's steps Shows "Loader Done" then shows the following errors
Error from vob database /vobstore/vobs/vobname.vbs.
Error Trouble Opening the VOB Database /vobstore/vobs/vobname.vbs,
Error Trouble Loading versioned object base /vobstore/vobs/vobname.vbs.
Because of the shared registry is this due to the existing registry entry and we need to unregister and then rmtag before registering and tagging fresh or do we need to do anything further?
Clearcase logs on aix vob server show:
DB Log - Error process not running on registery specified hostname (old win vob server)
Vob Log - shows unix UID and GID messange and Warning unable to verify mount options in vob tag registry Clearcase Object not found
David, there are a few things you need to do here:
unregister the VOB and remove all the tags that refer to the old server
reregister and retag the vobs at the new location.
If you can't register the VOB, run fix_prot -r -root ... to reset the ownership and try again.
run vob_sidwalk to remap object ownership.
run it again with -recover_filesystem to reset container ownership. Alternatively run checkvob -pool -protections -fix -force {vob storage dir}.
The last step really needed to be started on the Windows side before this started. Essentially, you needed a sid dump file to turn into the map file that the sidwalk needs (unless you want to remap everything to the VOB owner...)
The complete procedure to follow is at Moving VOBs between Operating system types You may want to start fresh from there if you still have the VOB located in the old location.
Solved. See my answer (but first see my second edit to the question).
I'm trying to restore a backup for a database from one computer on another - thereby copying the db, but I get this message:
System.Data.SqlClient.SqlError: The operating system returned the
error '5(Access is denied.)' while attempting
'RestoreContainer::ValidateTargetForCreation' on 'c:\Program
Files\Microsoft SQL Server...'. (Microsoft.SqlServer.SmoExtended)
Why is this? I can create new databases, so why not restore? Is it because it's from another computer? (I read that that's actually a usual way to copy a db so this shouldn't be the problem.)
I don't have much experience with this so don't rule out any obvious explanation.
EDIT :
I can 'restore' it using the administrator user account to the administrator's instance of SQL Server (I have two - one for the administrator, and one for the regular account.) but can't do it from either account to the regular user's instance of SQL Server.
EDIT 2 :
It seems that there are already existing files with the backup's files names (even though I changed the existing db's name). I'm working on that now (Trying, still unsuccessfully, to restore to different file names).
The solution was to make sure that the database was created in the MSSQL11.MSSQLSERVER folder (as opposed to the MSSQL10_50.SQLEXPRESS folder). Then SSMS succeeded in 'restoring' the database.
I just got this error with SQLSERVER14 .All I did is just checking the "Relocate all files to folder" checkbox in files tab of the restoration wizard.
The database got restored successfully.
Faced the similar problem. windows security is preventing to Restore the DB to 'Target' location. Fixing security settings can resolve this issue.
Right click on the Target folder-> Properties -> Security -> Select appropriate user and then Edit the permissions ( I have given Full Access to the user). Hope this would fix the problem.
When I got this error message my .bak file was located on my desktop (e.g."C:\Users\[username]\Desktop\database.bak").
When I moved the .bak file to my C drive instead the restore succeeded.
I want to restore a database from a file (Tasks → Restore → Database; after I select from device and select file) via SQL Server Management Studio.
After that, I get this error:
The operating system returned the error '5(Access is denied.)' while attempting
'RestoreContainer::ValidateTargetForCreation' on 'E:\Program Files\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\DATA\XXXXXX.mdf'.
Msg 3156, Level 16, State 8, Server XXXX, Line 2
How do I fix this problem? Is it a security error?
I recently had this problem. The fix for me was to go to the Files page of the Restore Database dialog and check "Relocate all files to folder".
The account that sql server is running under does not have access to the location where you have the backup file or are trying to restore the database to. You can use SQL Server Configuration Manager to find which account is used to run the SQL Server instance, and then make sure that account has full control over the .BAK file and the folder where the MDF will be restored to.
Well, In my case the solution was quite simple and straight.
I had to change just the value of log On As value.
Steps to Resolve-
Open Sql Server Configuration manager
Right click on SQL Server (MSSQLSERVER)
Go to Properties
change log On As value to LocalSystem
Hoping this will help you too :)
I just ran into this same problem but had a different fix. Essentially I had both SQL Server and SQL Server Express installed on my computer. This wouldn't work when I attempted to restore to SQL Express, but worked correctly when I restored it to SQL Server.
A good solution that can work is go to files > and check the reallocate all files
I tried the above scenario and got the same error 5 (access denied). I did a deep dive and found that the file .bak should have access to the SQL service account. If you are not sure, type services.msc in Start -> Run then check for SQL Service logon account.
Then go to the file, right-click and select Security tab in Properties, then edit to add the new user.
Finally then give full permission to it in order to give full access.
Then from SSMS try to restore the backup.
I was getting the same error while trying to restore SQL 2008 R2 backup db in SQL 2012 DB. I guess the error is due to insufficient permissions to place .mdf and .ldf files in C drive. I tried one simple thing then I succeeded in restoring it successfully.
Try this:
In the Restore DB wizard windows, go to Files tab, change the restore destination from C: to some other drive. Then proceed with the regular restore process. It will definitely get restores successfully!
Hope this helps you too. Cheers :)
There are several causes for this error, I got this error because I checked "Reallocate all files to folder" in the Files tab of Restore Database window but the default path did not exist on my local machine. I had the ldf/mdf files in another folder, once I changed that I was able to restore.
The operating system returned the error '5(access denied.)' when restoring database in sql server can be solved by enabling the Relocate all files to folder in the Files options as follows:
I found this, and it worked for me:
CREATE LOGIN BackupRestoreAdmin WITH PASSWORD='$tr0ngP#$$w0rd'
GO
CREATE USER BackupRestoreAdmin FOR LOGIN BackupRestoreAdmin
GO
EXEC sp_addsrvrolemember 'BackupRestoreAdmin', 'dbcreator'
GO
EXEC sp_addrolemember 'db_owner','BackupRestoreAdmin'
GO
In my case I had to check the box in Overwrite the existing database (WITH REPLACE) under Options tab on Restore Database page.
The reason I was getting this error: because there was already an MDF file present for the database and it was not getting overwritten.
Hope this will help someone.
If you're attaching a database, take a look at the "Databases to attach" grid, and specifically in the Owner column after you've specified your .mdf file. Note the account and give Full Permissions to it for both mdf and ldf files.
I had exactly same problem but my fix was different - my company is encrypting all the files on my machines. After decrypting the file MSSQL did not have any issues to accessing and created the DB. Just right click .bak file -> Properties -> Advanced... -> Encrypt contents to secure data.
this happened to me earlier today, i was a member of the local server's admin group and have unimpeded access, or i thought so. I also ticked the "replace" option, even though there is no such DB in the instance.
Found out that there used to be DB of the same name there, and the MDF and LDF files are still physically located at the data and log folders of the server, but the actual metadata is missing in the sys.databases. the service account of SQL server also can't ovewrwrite the existing files. Found out also that the files' owner is "unknown", i had to change ownership, to the 2 files above so that it is now owned by the local server's admin group, then renamed it.
Then finally, it worked.
The account does not have access to the location for backup file.
Take the following steps to access the SQL Server Configuration Manager via Computer Manager easily
Click the Windows key + R to open the Run window.
Type compmgmt.msc in the Open: box.
Click OK.
Expand Services and Applications.
Expand SQL Server Configuration Manager.
Change User Account in Log On As tab .
Now you can Restore Data Base easily
The fix for me was to go into Options when trying to Restore the database and change the path to the new path.
Here is the screenshot
I encountered the same problem, but my setup is a bit different.
I run my database in a linux docker container
sqlserver management tool in Windows.
What I did was:
sudo docker exec -u root -it sqlserver /bin/bash
This enters the docker container as a root user.
Then:
chmod 777 /path/to/file.bak
777 gives read, write & execute permissions to the file for any group, user