Acesso negado ao anexar um banco de dados

Estou usando o SQL Server 2008 developer edition. Eu estava tentando anexar o banco de dados AdventureWorks2008.

Quando tentei anexar, recebi um erro "acesso negado". De acordo com o log de eventos, ele veio do sistema operacional:

Falha na abertura: não foi possível abrir o arquivo D: \ ProjectData \ AdventureWorks \ AdventureWorksLT2008_Data.mdf para o arquivo número 0. Erro no SO: 5 (acesso negado.).

Eu pensei "problema no NTFS", mas o Sistema (e eu) modificamos o acesso aos dois arquivos.

Descobri que posso anexar o banco de dados com êxito se fizer login como sa, mas minha conta de usuário não funcionará.

Sou membro do grupo de administradores locais na minha máquina e estou na função sysadmins na instância do SQL Server.

Alguma idéia de por que eu tive que fazer login como sa?

Execute o SQL Server Management Studio como administrador. (clique direito-> executar como administrador) que cuidou de toda a estranheza no meu caso.

SQL SRV EXPRESS 2008 R2. Windows 7

Obrigado por todos os comentários. Alguns de vocês ajudaram a me levar à resposta. Aqui está o que eu encontrei:

Era um problema de permissão NTFS, e não um problema de SQL. Além disso, parece um tipo de bug (e é repetível).

O problema: a conta que eu estava usando tinha permissões NTFS de controle total para os arquivos mdf e ldf. No entanto, ele tinha essas permissões por meio da associação ao grupo (o grupo Administradores Locais tinha permissões e minha conta é membro de administradores locais). (Verifiquei as permissões)

Se eu tentar fazer a conexão, conecte-me ao SQL Server como eu (onde estou no grupo de administradores), ele falhará com o problema do NTFS.

No entanto, se eu conceder as mesmas permissões de arquivo que o grupo de administradores local possui diretamente à minha conta de domínio, posso anexar sem problemas.

(sim, verifiquei os grupos locais nesta máquina e verifiquei que minha conta de domínio é realmente um membro do grupo de administradores locais).

Portanto, parece que o erro ocorre porque algum código (no SQL Server ou no Management Studio) verifica as permissões que a conta do usuário possui, mas não chega a verificar as permissões do grupo que a conta do usuário herda.

Isso me parece estranho, mas eu posso reproduzi-lo repetidamente, então concluí que é a resposta.

Atualização: relatei isso como um bug: https://connect.microsoft.com/SQLServer/feedback/details/539703/access-denied-attaching-a-database-when-permissions-are-inherited

Gostaria de adicionar informações adicionais às respostas postadas.

Cuidado ao desanexar o banco de dados, pois o usuário do Windows no qual você está conectado se torna o único usuário com permissões para o arquivo .mdf! As permissões originais do arquivo .mdf, que incluíam o usuário SQLServerMSSQLUser$<computer_name>$<instance_name>e a conta Administradores, são substituídas pelo usuário do Windows em que você está conectado (e não pelo usuário do servidor sql). Boom, todas as permissões foram assim. Faça o que os outros disseram e clique com o botão direito do mouse no arquivo .mdf e verifique as permissões.

Corri para esse problema porque usei o SSMS para conectar-se ao banco de dados (não importa qual conta do servidor sql) e desanexei o banco de dados. Depois de fazer isso, meu usuário do Windows era o único que tinha permissões para o arquivo .mdf. Então, mais tarde, quando tentei anexar o banco de dados usando a conta sa, ele lançou o erro "acesso negado".

Para manter as permissões originais intactas, você deve colocar o banco de dados offline, desanexar e anexar nessa ordem da seguinte maneira:

USE [master]
GO
-- kick all users out of the db
ALTER DATABASE mydb
SET SINGLE_USER WITH ROLLBACK IMMEDIATE 
GO

-- Take the Database Offline
ALTER DATABASE mydb SET OFFLINE WITH
ROLLBACK IMMEDIATE
GO

-- detach the db
EXEC master.dbo.sp_detach_db @dbname = N'mydb'
GO

Adicione permissão à pasta onde está o seu .mdfarquivo.

Verifique este nome: NT Service\MSSQLSERVER

E mude Locationpara o nome do seu servidor.

Esse problema é causado pelo UAC (controle de conta de usuário), não é? Embora sua conta de usuário seja membro do grupo Administradores, o UAC no Windows 7 não permite que você faça coisas de administrador, a menos que execute programas "como administrador". Não é um bug real no SQL Server ou no Management Studio ou o que for. (Embora ele possa conhecer o problema e solicitar permissões elevadas em vez de apenas reclamar do "erro 5").

Execute o SQL Server Management Studio como administrador. (clique direito-> executar como administrador) funcionou para mim com o Windows 7 - SQL server 2008 R2

Um banco de dados SQL2005 pode ser anexado dessa maneira no Windows 7:

start menu >
 all program >
  Microsoft sql server 2005 >
   sql server management studio >
    right click >
     run as administrator >
      click ok

E o banco de dados anexado foi concluído com êxito.

Quando você faz login como sa(ou qualquer conta do Sql Server), você está funcionando como a conta de serviço do SQL Server; quando está conectado como você, você tem as permissões da sua conta. Por alguma razão, você não tem o acesso apropriado a arquivos, mas a conta de serviço possui.

Encontrei esta solução: Clique com o botão direito do mouse na pasta em que você armazena o arquivo .mdf -> clique em Propriedades -> escolha a guia Segurança, clique em Editar ... e conceda controle total. Espero que isto ajude!

O sausuário usa contas NTFS SQLServerMSSQLUser$<computer_name>$<instance_name>e SQLServerSQLAgentUser$<computer_name>$<instance_name>para acessar os arquivos do banco de dados. Você pode tentar adicionar permissões para um ou ambos os usuários.

Não sei se resolve o seu problema, pois você diz que não tem problemas com o sausuário, mas espero que ajude.

Comigo - Em execução na janela 8 - Clique em SQL Server Manager Studio -> Executar com o administrador. -> anexar sem problemas

Ele pode ser corrigido com facilidade, mas de maneira radical, basta ir para a pasta onde você armazenou o arquivo mdf . selecione arquivo-> clique com o botão direito do mouse -> clique em propriedades e dê permissões totais para arquivar para a segurança do usuário conectado .

Sempre que me deparei com esse problema, ao tentar anexar um banco de dados que esteja em um diretório diferente do diretório de banco de dados padrão configurado no SQL Server.

Eu recomendo que, em vez de conceder permissões em vários diretórios e contas, você simplesmente mova seu arquivo de dados para o diretório que o servidor sql espera encontrar.

Eu só queria adicionar essa informação também.

http://www.mssqltips.com/sqlservertip/2528/database-attach-failure-in-sql-server-2008-r2/

Solução

Você recebe esse erro porque dois logons diferentes fizeram as operações de desanexar e anexar. Portanto, os arquivos, quando desanexados, pertenciam ao primeiro logon, mas a conexão falhou porque o logon usado não era o proprietário dos arquivos mdf e ldf.

Quando desanexamos arquivos do banco de dados, o proprietário se torna a pessoa que executou o comando desanexar. Para resolver o problema, precisamos alterar ou adicionar o outro logon como proprietário dos arquivos mdf e ldf.

Clique com o botão direito do mouse no arquivo "filename.mdf" e selecione Propriedades para verificar as permissões do arquivo mdf. Aqui podemos ver que apenas uma conta tem permissão para o arquivo "filename.mdf" porque essa foi a conta usada para desanexar o banco de dados.

Para resolver esse problema, clique no botão Adicionar ... para adicionar o outro logon ou qualquer outro logon necessário e dar o controle total do logon. Você deve fazer isso no arquivo "ldf" também. Depois de concluir esta tarefa, clique no botão OK. (Observe que para outras versões do sistema operacional, você pode ter uma opção Editar, clique nela primeiro e depois verá a opção Adicionar ...).

Pelo que vale a pena para alguém que tenha a variação específica desse problema que eu tive:

• SQL Express 2008
• Visual Studio 2010 Premium

Através do menu de contexto da pasta App_data, eu criei um banco de dados SQL Express para fins de depuração. A cadeia de conexão (usada pelo NHibernate) foi a seguinte:

Server=.\SQLExpress;
AttachDbFilename=|DataDirectory|DebugDatabase.mdf;
Database=DebugDatabase;
Trusted_Connection=Yes;

Isso me deu o mesmo erro "Acesso negado" no arquivo do banco de dados. Tentei dar a vários usuários controle total para a pasta e os arquivos, a certa altura, até "Todos". Nada ajudou, então removi as permissões adicionadas novamente.

O que finalmente resolveu foi abrir o Server Explorer no Visual Studio, conectar-se ao MDF e desanexá-lo novamente. Depois que eu fiz isso, meu aplicativo Web pôde acessar o banco de dados muito bem.

PS. Os créditos vão para esta postagem do blog que encontrei ao pesquisar esse problema em particular, acionando a idéia de anexar / desanexar o banco de dados para resolver o problema.

Movi um banco de dados mdf da pasta Data padrão para a pasta asp.net app_data e me deparei com esse problema ao tentar definir o banco de dados novamente online.

Comparei as configurações de segurança dos outros bancos de dados de arquivos no local original com os arquivos movidos e notei que o MSSQL $ SQLEXPRESS não recebeu permissões para os arquivos em seu novo local. Adicionei controle total para "NT SERVICE \ MSSQL $ SQLEXPRESS" (deve incluir esse NT SERVICE) e ele foi anexado perfeitamente.

Parece que a pasta Dados original tem essas permissões e os arquivos a herdam. Mova os arquivos e as quebras de herança, é claro.

Verifiquei o arquivo mdf de outro projeto que criei diretamente na pasta app_data. ele não tem permissões MSSQL $ SQLEXPRESS. Hummm. Gostaria de saber por que o SQL Express gosta de um, mas não do outro?

Isso soa como permissões NTFS. Geralmente, isso significa que sua conta de serviço do SQL Server tem acesso somente leitura ao arquivo (observe que o SQL Server usa a mesma conta de serviço para acessar arquivos de banco de dados, independentemente de como você faz logon). Tem certeza de que não alterou as permissões da pasta entre o login como você mesmo e o login como sa? Se você desconectar e tentar novamente, ele ainda tem o mesmo problema?

Eu tive o mesmo problema ao anexar um banco de dados. Não era um problema de SQL, era um problema de conta. Vá para o painel de controle / Configurações de controle de conta de usuário / Defina como "nunca notificar". Finalmente, reinicie o computador e funcionou para mim.

Anexei o arquivo mdf clicando com o botão direito do mouse no banco de dados e removendo o arquivo de log AdventureWorks2012_Data_log.ldf no assistente. O arquivo mdf foi colocado no seguinte local

    C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\DATA

O método acima me ajudou a resolver o problema.

Eu estava lendo esta página e eles têm uma frase interessante lá:

Cuidado: Seja muito seletivo ao adicionar usuários a essas funções. Por exemplo, o sysadmin mapeia para o dbo em todos os bancos de dados e é o equivalente a efetuar login usando a conta sa.

Claro, eles também têm isso:

Permissões concedidas a usuários e funções e são específicas do banco de dados. Todas as permissões são cumulativas, com exceção de um DENY. Uma permissão negada no nível do usuário ou no nível da função substitui a mesma permissão concedida por outras associações de função, com exceção da função de servidor fixa sysadmin. (Um administrador de sistema mantém todas as permissões, mesmo que uma função da qual ele seja membro tenha uma permissão DENY.)

Portanto, se você é um administrador de domínio e no grupo 'sysadmin' do SQL, o mundo deve ser o seu crustáceo.

Obviamente, de acordo com a Microsoft, você deve dar uma olhada rápida nessas duas páginas:
Link para os pré-requisitos do banco de dados

Link para instalação de bancos de dados

Você está sendo malcriado e tentando anexá-los manualmente :) Sério, você tem todos os pré-requisitos para o banco de dados AdventureWorks2008?
Suspeito que este seja apenas outro caso de estranheza / borda da Microsoft, mas posso estar errado.

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH
GO

mude para FOR ATTACH -> FOR ATTACH_FORCE_REBUILD_LOG

USE [master]
GO
CREATE DATABASE [DataBasename] ON 
( FILENAME = N'C:\data\DataBasename.mdf' )
 FOR ATTACH_FORCE_REBUILD_LOG
GO

Eu recebi esse erro como sa. No meu caso, a segurança do banco de dados não importava. Adicionei controle total a todos os arquivos mdf e ldf e o anexo correu bem.

Eu estava enfrentando o mesmo problema no VS 2019. Se alguém ainda estiver enfrentando o mesmo problema, verifique se você tem / faz o seguinte:

1. Você deve ter o SQL Express instalado no seu m / c
2. Deve ter o SSDT instalado no VS (no VS 2019 - verifique este componente durante a instalação) para versões anteriores - você deve adicionar esse componente externamente
3. Adicione 'User Instance = True' à sua string de conexão
4. Eu acho que é opcional - abra o VS e o SQL Express no modo administrativo e faça o login como administrador no SQL Express

Na verdade, são permissões NTFS e um bug estranho no SQL Server. Não tenho certeza se o relatório de bug acima é preciso ou pode se referir a um bug adicional.

Para resolver isso no Windows 7, executei o SQL Server Management Studio normalmente (não como administrador). Eu tentei anexar o arquivo MDF. No processo, usei a interface do usuário em vez de colar no caminho. Percebi que o caminho estava isolado de mim. Isso ocorre porque o usuário do MS SQL Server (SQLServerMSSQLUser $ machinename $ SQLEXPRESS) que o software adiciona para você não tem permissão para acessar a pasta (nesse caso, uma pasta nas minhas próprias pastas de usuário).

Colar o caminho e continuar resulta no erro acima. Então - eu dei ao usuário do MS SQL Server permissões para ler a partir do primeiro diretório do qual foi negado (minha pasta de usuário). Em seguida, cancelei imediatamente a operação de propagação porque ela pode levar uma eternidade e apliquei novamente as permissões de leitura para a próxima subpasta necessária, deixando a propagação completa.

Finalmente, dei ao usuário do MS SQL Server permissões de modificação para os arquivos .mdf e .ldf do banco de dados.

Agora posso anexar aos arquivos do banco de dados.

Se você executar o sql server 2012, poderá obter esse erro tentando anexar uma versão mais antiga de um arquivo mdf. ex um arquivo mdf do sql server 2008.

Para solucionar o problema, basta mover o arquivo .mdf que você deseja anexar à pasta pública; no meu caso, movi-o para a pasta users / public. Então eu anexo a partir daí sem nenhum problema. Espero que isto ajude.

Para aqueles que não conseguiram resolver o problema com as outras soluções aqui, a seguinte correção funcionou para mim:

Vá para a pasta "DADOS" na instalação do SQL Server, clique com o botão direito do mouse, propriedades, guia segurança e adicione permissões de controle total para o usuário "SERVIÇO DE REDE".

http://decoding.wordpress.com/2008/08/25/sql-server-2005-expess-how-to-fix-error-3417/

(O link acima é para o SQL 2005, mas isso corrigiu uma instalação do SQL 2008 R2 para mim).

Algumas informações adicionais: Esse problema apareceu para mim depois de substituir um disco rígido secundário (em que a instalação do SQL estava ativada). Copiei todos os arquivos e restaurei a letra da unidade original no novo disco rígido. No entanto, as permissões de segurança não foram copiadas. Acho que da próxima vez usarei um método melhor de copiar dados.

No meu caso, o que resolveu o problema foi o seguinte:

USE [master]
GO
CREATE DATABASE [AdventureWorks2008R2] ON
( FILENAME = 'C:\Program Files\Microsfot SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\DATA\AdventureWors2008R2_Data.mdf')
FOR ATTACH_REBUILD_LOG

Copie o banco de dados para outra pasta e anexe ou efetue login no SQLServer com "Autenticação do Windows"

Eu tive o mesmo problema ao anexar novamente o banco de dados após desanexá-lo e mover arquivos ldf e mdf da unidade C para F.

Para corrigi-lo, tive que adicionar o principal OWNER RIGHTS aos dois arquivos e dei controle total sobre eles na guia Segurança da caixa de diálogo Propriedades.