From: mat on
In article <uOTn1G7fJHA.5724(a)TK2MSFTNGP02.phx.gbl>,
tibor_please.no.email_karaszi(a)hotmail.nomail.com says...
> > You're probably right, but I couldn't figure it out and didn't get
> > input
> > that helped solve it in the original post here.
>
> The error message is very clear: The service account doesn't have
> permissions to put the database files where you request (per default
> same path as originating database). There is no ambiguity for the
> operating system error 5. Use the MOVE option for the RESTORE command
> if needed.
>
>
Tibor you were right; what a help. The path SSMS selected for the
restore didn't include the \data dir at the end, for some reason. I
would not have thought that sql server would be so picky re the ability
to restore to another location, but that was it. I was already using
MOVE.

The path to the data files on the orig server is not identical to what
the path must be on the destination server. You said that the default is
to use the same path; since that wouldn't have been valid, I guess ssms
did the best it could but got it wrong.
From: Tibor Karaszi on
There's a configuration for default database file path somewhere you
in SSMS. Maybe this is what is used and this isn't as desired? Just a
guess...

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"mat" <mat(a)notarealdotcom.adr> wrote in message
news:MPG.23e9c2bbfe83aa7c989775(a)msnews.microsoft.com...
> In article <uOTn1G7fJHA.5724(a)TK2MSFTNGP02.phx.gbl>,
> tibor_please.no.email_karaszi(a)hotmail.nomail.com says...
>> > You're probably right, but I couldn't figure it out and didn't
>> > get
>> > input
>> > that helped solve it in the original post here.
>>
>> The error message is very clear: The service account doesn't have
>> permissions to put the database files where you request (per
>> default
>> same path as originating database). There is no ambiguity for the
>> operating system error 5. Use the MOVE option for the RESTORE
>> command
>> if needed.
>>
>>
> Tibor you were right; what a help. The path SSMS selected for the
> restore didn't include the \data dir at the end, for some reason. I
> would not have thought that sql server would be so picky re the
> ability
> to restore to another location, but that was it. I was already using
> MOVE.
>
> The path to the data files on the orig server is not identical to
> what
> the path must be on the destination server. You said that the
> default is
> to use the same path; since that wouldn't have been valid, I guess
> ssms
> did the best it could but got it wrong.