Błąd przywracania programu SQL Server - odmowa dostępu


167

Utworzyłem bazę danych na moim komputerze lokalnym, a następnie wykonałem kopię zapasową o nazwie tables.baktable DataLabTables.

Przeniosłem tę kopię zapasową na komputer zdalny bez tej tabeli i próbowałem przywrócić, ale otrzymałem następujący błąd:

System.Data.SqlClient.SqlError: System operacyjny zwrócił błąd „5 (odmowa dostępu.)” Podczas próby „RestoreContainer :: ValidateTargetForCreation” na „c: \ Program Files \ Microsoft SQL Server \ MSSQL.1 \ MSSQL \ DataLabTables” .mdf ”.

Jak mogę naprawić swoje prawa, jeśli na tym polega problem?

Odpowiedzi:


539

Właśnie miałem ten problem z SQL Server 2012.

Okazuje się, że wszystko, co musiałem zrobić, to zaznaczyć pole „Przenieś wszystkie pliki do folderu” w sekcji „Pliki”:

wprowadź opis obrazu tutaj

(Kliknij, aby zobaczyć obraz w pełnym rozmiarze)

To oczywiście zakłada, że ​​masz zainstalowaną poprawną wersję SQL Server.


13
U mnie też zadziałało. Czy ktoś może wyjaśnić, dlaczego ?
magnattic

3
Czy możesz również podzielić się, jak można to zrobić za pomocą skryptu zamiast interfejsu użytkownika?
FMFF

9
Miałem ten problem z 2014, ta sama poprawka.
DaneEdw

3
Było to również rozwiązanie dla mnie podczas tworzenia kopii zapasowej z SQL Express i przywracania do pełnego serwera SQL
tarrball,

10
MUSZĘ CIĘ PRZYGOTOWAĆ. A teraz poważnie, już miałem odmówić klientowi, twoja odpowiedź uratowała mój projekt.
Marco Scabbiolo

30

Z komunikatu o błędzie wynika, że ​​wystąpił błąd podczas sprawdzania poprawności celu ( c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DataLabTables.mdf) operacji przywracania.

To brzmi jak:

a) ten plik już istnieje (ponieważ został już przywrócony) i jest używany przez SQL Server

lub

b) ten katalog w ogóle nie istnieje

W swoim pytaniu wspomniałeś, że utworzyłeś kopię zapasową tej tabeli - nie tak działają kopie zapasowe SQL Server. Te kopie zapasowe to zawsze cała baza danych (lub co najmniej jedna lub kilka grup plików z tej bazy danych).

Moje przeczucie jest takie: już wcześniej przywróciłeś tę bazę danych, a teraz, przy drugim przywracaniu, nie zaznaczyłeś pola wyboru „Zastąp istniejącą bazę danych” w kreatorze przywracania - w ten sposób istniejący plik nie może zostać nadpisany i przywracanie się nie powiedzie.

Użytkownik, który uruchamia przywracanie na serwerze zdalnym, oczywiście nie ma dostępu do tego katalogu na serwerze zdalnym.

C:\program files\.... jest katalogiem chronionym - zwykli użytkownicy (nie będący administratorami) nie mają dostępu do tego katalogu (i jego podkatalogów).

Najłatwiejsze rozwiązanie: spróbuj umieścić plik BAK w innym miejscu (np. C:\temp) I przywróć go stamtąd


Próbowałem pod C: \ temp, ale błąd nadal jest taki sam jak powyżej, z tą samą ścieżką, o której wspomniałem na początku, co jest dziwne
cdub


1
@marc_s thx, zapomniałem edytować opcje, ponieważ nie ma katalogu dla tego pliku ... to nie jest ... MSSQL \ DataLabTables.mdf, ale zamiast tego ... MSSQL \ Data \ DataLabTables.mdf
cdub

2
@marc_s: Drobny komentarz dotyczący części opcji A wymienionej powyżej „i jest używana przez SQL Server”: Okazuje się, że standardowe RESTOREpolecenie nie powiedzie się, jeśli plik istnieje, nawet jeśli nie jest używany przez SQL Server (np. MDF / Pliki LDF pozostają na miejscu po poprzednim odłączeniu). Natknąłem się na to w niestandardowej implementacji wysyłania dzienników opartej na T-SQL w celu przeprowadzenia poważnej migracji setek baz danych w ciągu ostatnich kilku tygodni. Nie jestem pewien, czy komunikat o błędzie brzmiał „odmowa dostępu”, mógł być mniej konkretny.
Tao

2
Musiałem ręcznie zmienić nazwę istniejących plików MDF / LDF, zanim mogłem przywrócić za pomocą kopii zapasowej - zaznaczenie opcji „Zastąp” nie wystarczyło.
Jamie Keeling

26

Miałem ten sam problem. Okazało się, że moje SQL Serveri SQL Server Agentusługi logon asdziałały na Network Serviceskoncie, które nie miało uprawnień do zapisu, aby wykonać przywrócenie kopii zapasowej.

Zmieniłem obie te usługi, aby logowały się jako Local System Accounti to rozwiązało problem.


To nie jest dobry pomysł. Maskuje prawdziwy problem, czyli lokalizacja pliku, do którego próbujesz przywrócić, nie jest tym, co zamierzasz.
declouet

2
Moja usługa SQL Server działała pod adresem „Usługa NT \ MSSQLSERVER”, dodając uprawnienia tego użytkownika do folderu danych i dziennika.
Tim Newton,

W porządku, to mi pomogło
Aliaksei Zhukau,

9

Niedawno spotkałem się z tym problemem w SQL 2008 R2 i poniższe rozwiązanie zadziałało:

1) Utwórz nową bazę danych o takiej samej nazwie, jak ta, którą próbujesz przywrócić 2) Podczas przywracania użyj tej samej nazwy, której użyłeś powyżej i w opcjach kliknij opcję nadpisania

Możesz dać powyższemu szansę, jeśli inne rozwiązania nie działają.


6

Twórca kopii zapasowej miał zainstalowany MSSql w wersji 10, więc kiedy wykonywał kopię zapasową, przechowuje również oryginalną ścieżkę do pliku (aby móc przywrócić ją w tej samej lokalizacji), ale miałem wersję 11, więc nie mógł znaleźć katalogu docelowego.

Więc zmieniłem katalog plików wyjściowych na C: \ Program Files \ Microsoft SQL Server \ MSSQL11.MSSQLSERVER \ MSSQL \ DATA \ i udało mi się pomyślnie przywrócić bazę danych.

Źródło


6

Miałem podobny problem. Próbowałem przywrócić plik .bak 2005 i otrzymałem dokładnie ten sam błąd. Bezskutecznie wybrałem również opcję nadpisywania.

moim rozwiązaniem było przyznanie użytkownikowi SQL dostępu do danego katalogu, przechodząc do folderu i edytując prawa dostępu na ekranie właściwości.


2

też straciłem kilka godzin na ten problem. ale to działa:

„odmowa dostępu” w moim przypadku naprawdę oznaczała „odmowa dostępu”. Konto użytkownika mssqlstudio na moim urządzeniu z systemem Windows NIE miało pełnej kontroli nad folderem określonym w komunikacie o błędzie. dałem mu pełną kontrolę. nie odmówiono już dostępu i przywrócenie powiodło się.

dlaczego folder został zamknięty dla studia? kto wie ? Mam wystarczająco dużo pytań, aby sobie z nimi poradzić bez próbowania odpowiedzi na więcej.


1

Miałem ten problem, zalogowałem się jako administrator i naprawiłem problem.


Pracował dla mnie również dla SSMS v17
Nandolcs

0

Innym scenariuszem może być istnienie wielu ścieżek do bazy danych. Najpierw zanotuj ścieżkę, w której są obecnie przechowywane nowe bazy danych. Więc jeśli utworzysz nową pustą bazę danych, a następnie to zrobisz Tasks/Restore, upewnij się, że ścieżka, której próbuje użyć przywracanie, jest tym samym katalogiem, w którym została utworzona pusta baza danych. Nawet jeśli ścieżka przywracania jest legalna, nadal będziesz mieć odmowę dostępu błąd, jeśli nie jest to bieżąca ścieżka, z którą pracujesz. Bardzo łatwo zauważyć, kiedy ścieżka nie jest legalna, znacznie trudniej zauważyć, kiedy ścieżka jest legalna, ale nie obecna ścieżka.


0

Przepraszam, bo nie mogę komentować ...

Miałem ten sam problem. W moim przypadku problem był związany z próbą przywrócenia w starym folderze serwera sql (który istniał na serwerze). Jest to spowodowane przywróceniem starej kopii zapasowej serwera sql (tj. SQL Server 2012 Backup) na nowym serwerze sql (SQL Server 2014). Prawdziwy problem nie różni się zbytnio od odpowiedzi @marc_s. W każdym razie zmieniłem tylko folder docelowy na nowy folder DATA serwera SQL.


0

Może to nie jest najlepsze rozwiązanie, ale próbowałem przywrócić dane w SQL Server 2005, ale przeszedłem na SQL Server 2008 i zadziałało.



0

Frnds ... Miałem ten sam problem podczas ograniczania bazy danych i próbowałem każdego rozwiązania, ale nie udało mi się go rozwiązać. Następnie próbowałem ponownie zainstalować SQL 2005 i problem został rozwiązany. Ostatnio zapomniałem sprawdzić opcję dostosowywania podczas instalowania SQL .. Podczas instalacji pojawia się dwa razy i sprawdzam tylko jeden raz.


0

W moim przypadku - musiałem dwukrotnie sprawdzić ścieżkę kopii zapasowej bazy danych, z której przywracałem. Wcześniej przywróciłem go z innej ścieżki, kiedy robiłem to po raz pierwszy. Naprawiłem ścieżkę kopii zapasowej, aby użyć ścieżki kopii zapasowej, której użyłem za pierwszym razem i zadziałało!


0

Skończyło się na utworzeniu nowych folderów dla danych i dzienników i działało poprawnie, musiał być problem z uprawnieniami do folderu / pliku.


0

Dzieje się tak również, jeśli ścieżki są poprawne, ale konto usługi nie jest właścicielem plików danych (a mimo to ma wystarczające uprawnienia do odczytu / zapisu). Może się tak zdarzyć, jeśli uprawnienia do plików zostały zresetowane, aby odpowiadały uprawnieniom folderu (oczywiście, gdy usługa została zatrzymana).

Najłatwiejszym rozwiązaniem w tym przypadku jest odłączenie każdej bazy danych i ponowne jej dołączenie (bo przy dołączaniu właściciel zmienia się na konto serwisowe).


-1

Spróbuj tego:

W oknie kreatora przywracania bazy danych przejdź do zakładki Pliki, odznacz pole wyboru „Przenieś wszystkie pliki do folderu”, a następnie zmień miejsce docelowe przywracania z C: na inny dysk. Następnie kontynuuj zwykły proces przywracania. Zostanie pomyślnie przywrócony.


-1

Miałem ten sam problem, ale użyłem serwera sql 2008 r2, musisz sprawdzić opcje i zweryfikować ścieżki, w których sql zamierza zapisać pliki .mdf i .ldf, musisz wybrać ścieżkę instalacji serwera sql. Rozwiązałem swój problem z tym, mam nadzieję, że ci to pomoże.


-2

Następnie spróbuj przenieść go do podfolderu pod C :, ale sprawdź, czy użytkownik ma pełne prawa do folderu, którego używasz.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.