Results 1 to 3 of 3

Thread: xp_cmdshell Behavior

  1. #1
    Ed Molinari Guest

    xp_cmdshell Behavior

    Hi all,
    I have a question regarding some very odd NT/SQL behavior that is exhibited when running a shell command through xp_cmdshell. If I do a 'net use z: \servernamesharename' from the xp_cmdshell, it shows up in Explorer with the icon for a local drive! This would not be more than an ordinary M$ bug, except for the fact if go to a command line, I can't do a 'net use z: /delete' because it says that the network drive isn't there! Can someone shed some light on this?

    Thanks,
    Ed Molinari
    Emerald Solutions

  2. #2
    Kenneth Wilhelmsson Guest

    xp_cmdshell Behavior (reply)

    Hi Ed.

    Are you running the SQL Server as a Local System?
    Wild guess, but could it have something to do with who owns z: after it's mapped?
    I believe that Local System account is not quite the same as Administrator.
    I replicated your scenario on a Local System server, and sure enough it does what you say. Haven't tried it in a server running a domain account, though.

    However, it's no problem deleting with xp_cmdshell 'net use z: \servershare /delete'
    The server can close what it opened alright.

    Could be a bug, but on the other hand I can't really see any use for mapping a network drive through xp_cmdshell for other users than the SQLserver service.

    /Kenneth
    ------------
    Ed Molinari at 5/28/99 2:12:44 PM

    Hi all,
    I have a question regarding some very odd NT/SQL behavior that is exhibited when running a shell command through xp_cmdshell. If I do a 'net use z: \servernamesharename' from the xp_cmdshell, it shows up in Explorer with the icon for a local drive! This would not be more than an ordinary M$ bug, except for the fact if go to a command line, I can't do a 'net use z: /delete' because it says that the network drive isn't there! Can someone shed some light on this?

    Thanks,
    Ed Molinari
    Emerald Solutions

  3. #3
    Kenneth Wilhelmsson Guest

    xp_cmdshell Behavior (reply)

    Hi Ed.

    I'll post your reply to my e-mail account for others to share. After all, that's was makes a discussion live. =;-)

    Can't you use UNC paths like \serversharefile to do whatever the proc is doing? It should certainly work for moving files and such.
    Don't sure if the mssqlserver account needs to be a proper domain user though.
    At any rate, it needs to have the appropriate permissions set on the remote share for whatever it wants to do.

    If UNC style works for you, you should be able to drop the net use approach.
    /Kenneth

    Hi Kenneth,
    Thanks for answering the SQL post in swynk.com. I just wanted to give you
    the background dope on what's going on.
    The MSSQLServer and SQLExecutive services are running as Local Admin
    accounts. We have to manage our servers through local accounts because our
    client won't give us domain access. But these services are not running as
    LocalSystem.
    The purpose of the mappings is a stored procedure that runs as a scheduled
    task that automates the processing of ftp feeds that come into a web server.
    The stored procedure connects to the mapped drives, does what it does, then
    disconnects the mappings. Intermittently, it does not disconnect the
    mappings. When this happens, the drives show up as you saw them: local
    drives. If you try to disconnect them with the 'cmd' prompt, you will be
    told that the network drive does not exist. This causes the stored
    procedure to fail.
    Theory would have it that the xp_cmdshell would then be able to delete the
    drive mapping. Ah..if life were so easy. It seems that if the disconect
    fails the first time, it will fail on a successive attempt. I have the 'net
    use x: /delete' at the beginning and end of the stored procedure in case
    another admin has mistakenly left a drive mapped. I wind up having to stop
    the WorkStation service to get rid of the mapping.
    I can't find a pattern to this. I could live with the obscurity if it did
    not interfere. Any thoughts on another way to get at the data without
    going through this?

    Thanks so much,
    Ed Molinari
    Senior Technical Architect
    Emerald Solutions
    9086585227

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •