Re: SQL Server Can Not See Shared Drive

Sue,

Thanks again. This time you hit a bit closer. Yes, I was expecting to see
non local drives in the database file window so I can put the MDF and LDF on
a different network drive. The link you gave me confirms that I just can't do
that. Plus, my interpretation of detaching a mdf/ldf file set and putting it
on a network share and reattaching it would thus not work either - it is
still a network share.

Thanks for the help. This resolves it.

MG

"Sue Hoegemeier" wrote:

I'm not sure that is really what you are doing. You keep
referring to mapped drives. You should not be using mapped
drives. You should be using UNC paths. I'm not sure what you
mean by a shared drive - a share or a mapped drive or a UNC
path to a share?
Are you expecting to see non-local drives from another
server show up as drive letters? That is a mapped drive
(typically - SAN volumes will be seen as a drive letter),
not a UNC path. When you say you are expecting to "see"
mapped drives, that kind of sounds like you are not using
UNC paths.
Also, putting the data files on network drives like this
isn't recommended. You need to place them on local drives
(or DAS) or on SAN volumes which would appear as local
drives. Refer to the following article:
Description of support for network database files in SQL
Server
http://support.microsoft.com/?id=304261

-Sue

On Thu, 24 Aug 2006 12:29:02 -0700, MG
<MG@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

Sue,
Thanks but that is pretty much what I am doing. SQL is starting under a
domain account. That account has full priviledges and rights accross the
entire network. To help you understand what I am seeing, here is an example.
If I decide to creat a new database and select Database and right click New
Database. The enter a name, (i.e. TestToday) and go to the Database file tab.
Then select Location to put the MDF in a shared drive, there is nothing that
appears in the window except the C drive. I am expecting to be able to put
the MDF on another location at that point. I am expecting to see the other
mapped drives that the domain account I am using can see. The domain account
can see the drive I want to put the MDF on but SQL can not and sql is running
under that SAME domain account.

Let me know if you have any other ideas.

Thanks,
MG

"Sue Hoegemeier" wrote:

Mapped drives are profile dependent. And they are not all
that reliable with services due to them being profile based.
You always want to use UNC paths instead of mapped drives.
The references to network locations should be in the form
of:
\\ServerName\ShareName
If you are accessing network resources, you need to be using
a domain account for the SQL service account.

-Sue

On Thu, 24 Aug 2006 08:02:02 -0700, MG
<MG@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

It all stared by observing and error when running Bulk Insert with a sp where
the input file was on the C drive – it was fine. Then I switched to where the
file was on a shared network drive – it failed with Access Denied. I did a
work around which works fine but did not still resolve the Access Denied
issue.

I then started thinking about the SQL security. I was wondering if SQL
itself could see a shared drive. For example, making a Device to a different
drive or even setting up the MDF/LDF to a new database to a different drive.
My test proved that it failed on all counts. It could only see the C drive.

After my research, I discovered first that SQL was starting under Local
System account. I changed that to a domain account that has absolutely full
System Administrator writes and can see everything on our environment. I then
tried making a new database and putting the MDF/LDF to a mapped shared drive.
It could not see the shared drive – period.

I am running Windows Server 2003 and SQL Server 2000. The domain account I
am using to start SQL Server has full rights and can see the environment.

Before I have to open the checkbook and call MS to open a ticket, do you
have any suggestions?

MG




.

Relevant Pages

  • Re: Advice Requested : Disaster Recovery with 2 Drives (No Raid) with SQL Server 2008
    ... so we need frequent copies of the database for testing, ... Andrew J. Kelly SQL MVP ... But by placing the backups on the same drive as the data or logs you risk loosing data if one of the drives crashes since you will loose backups and either the log or data files. ...
    (microsoft.public.sqlserver.programming)
  • Re: Cool boat & travel computer
    ... For the "new" PCXT, the biggest FULL HEIGHT hard drive was the Tulin ... drives and 256K of RAM. ... these nice 9-track drives with bus adapter cards and drivers in Computer ... run the custom database, print perfect Meter Cards so the technicians on ...
    (rec.boats.cruising)
  • Re: SQL 2005 Best Practice vs SQL 2000: Application Files Separate from data (and log) files
    ... You'll not be using most of the system databases intensively so you don't need to seperate them, I mean locating them on different physical disks. ... If it's being used intensively in your environment then you should locate it's log and data files on different physical disks. ... For this question you must understand the reason why we should seperate data and log files. ... Of course these drives must be physically seperated so that you'll gain performance benefits. ...
    (microsoft.public.sqlserver.setup)
  • Re: New install of SBS and where to put SQL and exchange
    ... One thing to add about partitions though - shadow copy also has a bearing on ... database drives so those should be separate from user data which you do want ... SBS is one busy machine, exchange and sql, are ... drives with a multi-channel RAID controller? ...
    (microsoft.public.windows.server.sbs)
  • Proper way to move Log files to another drive
    ... For speed, I have separate drives for OS, SWAP, APPS, SQL, and LOGS. ... the APPS drive, and it created its database, and log file, in the default ...
    (microsoft.public.sqlserver.setup)