RodgerFlint has asked for the wisdom of the Perl Monks concerning the following question:

I've been working on an ASP using PerlScript under IIS 6.0. Recently I was told that the directory that I've been walking needs to be moved to another server and the only way I can interact with it is though a UNC file path. Alas, the script that worked fine with local directories can't see the UNC directories at all when run through an ASP page.

For instance, this works fine from the command prompt:
use strict; use warnings; use Data::Dumper; my $path = '//myuncserver/wwwroot$'; my @entry = stat($path) or die "Couldn't stat $path : $!"; print Dumper(@entry);
but doesn't work from the ASP page.
<%@ LANGUAGE="perlscript" > <% use strict; use warnings; use Data::Dumper; use vars qw($Response); my $path = '//myuncserver/wwwroot$'; my @entry = stat($path) or die "Couldn't stat $path : $!"; $Response->Write(Dumper(@entry)) %> PerlScript Error error '80004005' (in cleanup) Couldn't stat //myuncserver/wwwroot$ : No such file or di +rectory /testdir/walk2.asp, line 8
Does anyone have any idea what magic spell I need to cast over IIS to get it to be able to read a UNC path from a ASP PerlScript page?

Thanks!

Replies are listed 'Best First'.
Re: Reading UNC File Paths from ASP PerlScripts
by terra incognita (Pilgrim) on Apr 12, 2005 at 16:24 UTC
    This probably has less to do with IIS than with account permissions. When you run it from the command line it is run under your account which has permission to that network resource. By default IIS runs under a special account called "Local System". The Local System account has access to almost all resources on the local machine not specifically denied to it, and no resources on any other machines on the network.
    MS KB article 158229 has more info about security and IIS applications.
    Do you really need to walk that directory?
    Perhaps there is another method you could use?
      Thanks for both of your posts. That makes a lot of sense.
Re: Reading UNC File Paths from ASP PerlScripts
by NetWallah (Canon) on Apr 12, 2005 at 19:52 UTC
    As terra incognita points out - this is a security issue.

    For ASP pages, if you allow anonymous access, the pages run with a local computer account named "IUSER_<machine-name>". This account typically cannot access shares on other computers.

    The simplest solution for you may be to TURN OFF anonymous access to the page, and make sure whoever accesses your page has access to the remote share.

    More complicated solutions involve creating an appropriate domain account, and making the page a part of a web application that runs under that account.

         "There are only two truly infinite things. The universe and stupidity, and I'm not too sure about the universe"- Albert Einstein