Is SlimServer running as a service logged in under the SYSTEM account?  If so, this is well-known and not a bug.  If you're seeing this when SlimServer is run as a user process then there's some other problem.  The SYSTEM account doesn't normally have access to network resources, so you should set up a new XP user account and use that account to run the SlimServer service.  I believe this is one reason that SlimTray now has the option to run SlimServer at login - to avoid this problem.

But maybe I'm missing something... I would think support deals with this issue almost daily.

Even the FAQ isn't fully correct on this issue.... (http://slimdevices.custhelp.com/cgi-bin/slimdevices.cfg/php/enduser/std_adp.php?p_faqid=5967&p_created=1168473234&p_sid=CcO9vtHi&p_accessibility=0&p_lva=&p_sp=cF9zcmNoPTEmcF9zb3J0X2J5PSZwX2dyaWRzb3J0PSZwX3Jvd19jbnQ9NCZwX3Byb2RzPTAmcF9jYXRzPSZwX3B2PSZwX2N2PSZwX3NlYXJjaF90eXBlPWFuc3dlcnMuc2VhcmNoX25sJnBfcGFnZT0xJnBfc2VhcmNoX3RleHQ9c2hhcmU*&p_li=&p_topview=1):

"If you are running on Windows NT, 2000 or XP, SlimServer is running as Windows service. Windows services do not have permission to use networked drives by default. The only way that can work is if you set the service to have the capability to interact with the desktop, which can sometimes cause some undesirable behavior, and is known to not work properly in many cases."

Jim's approach (run the service as a user with appropriate permissions) is the way to go. No bug.

Oh, btw: we're hearing this a _lot_ in the forums. IMHO one of the most frequently asked questions.

It's actually possible to create a user account from within a Windows installation script and then use that account as the login for the newly installed service.  If that could be done it would solve this problem once and for all.

I know this is possible because I've installed a package (ISC BIND) on Windows that does exactly this.  During the installation, the installer simply asks for a password for the account and then does the rest.  I'm guessing this requires Administrator privileges, so couldn't say what hurdles you might have in trying to do this in Vista.  I would assume the installer could fall back to using the standard SYSTEM account if it's unable to create the user account.

It's worth running the BIND Windows installer, just to see how well it works.  The program is easily uninstalled afterwards if you've no need for a DNS server.  It's also open source, so the intaller code should be available.

http://www.isc.org/sw/bind/

We briefly discussed the creation of an user account during installation. But as the number of people using such a configuration is very low, we won't do this now. Vista has added a little more complexity to it all, and our installer software doesn't allow for easy creation of accounts. A good FAQ article should/could compensate for this.

Chances are I'm just crazy but I thought even while SlimServer was running as a service (default installation, not automatically run at login) SlimServer could still access UNC paths, just not mapped drive letters. How did we access network drives before automatically run at login? 

Dan and I noticed some interesting behavior earlier while testing. We noticed that SlimServer while running as a service (not automatically run at login) that we could not give a UNC path to an XP share, but we could give a UNC path to a debian share. Is this normal?

Accessing shares is possible as long as these shares allow for anonymous accounts. This can be configured in Windows as well as on Linux/Samba.