You're missing a few special issues with Win here:
The limited user as itself is not the problem but the way the software is started as a limited user.
Runas != normal program start as user. If you login as that user and then start the program should work OK (can't test as I have no console access and don't want to add mercury user to various groups).

Also the switch /env changes the environment to be used to "to use current environment instead of user's." Thus the Admins Temp dir for writing temporary files (*this* behavior will have changed from 4.7.4 to 4.8: in 4.7.4 mercury.ini was written directly to, now it behaves as if a temp file is created and moved.)

 Also your conclusion is wrong as  the command that reproduces the error actually *is* issued from C:\Mercury ("cd C:\Mercury").

Sorry but that's how it is over here.

I just upgraded to v4.80.  On startup MercuryI fails to start popping up a message that says "No such file or directory".  Paths in the MercuryI section of the mercury.ini file are valid.  Thoughts?

I just got past the problem by firing up MercuryS and creating a new certificate with a .PEM extension and then modifying the path in mercury.ini accordingly.  The previous certificate did not have a file extension.

Self-signed certificates created by earlier versions of Mercury are as far as I remember not usable any more in v4.80 due to the old encryption package being replaced by OpenSSL. Creating a new certificate is easy, though.

I thought the new certificate file had solved the problem but it hadn't.  What I have since discovered is that when Mercury is started by a batch file at startup MercuryI fails to load and the "No such file or directory" popup is displayed.  If I then shutdown Mercury and manually run loader it starts up fine.

That batch file exists to first start POPFile, provide a 15 second delay to allow it to completely load, and then run loader.exe.  There were no other changes made at the time of the upgrade to v4.8.  I am going to spend some time during off hours to troubleshoot this by increasing the delay and changing the directory to c:\mercury before running loader.  I welcome any other suggestions on potential causes of the problem.

I've noticed that when running Mercury as a service, and possibly in other cases when the program isn't started directly, it may be necessary to include full paths to for instance certificate files (i.e. C:\Mercury\my-cert.pem).

That was what I first suspected but all of the paths in the mercury.ini file are full paths.  The command line in the batch file is c:\mercury\loader.exe so when I find the opportunity to troubleshoot I am going to try setting the directory first like...

c:
cd\
cd mercury
loader.exe

An unknown is whether the popup error message is preventing MercuryI from loading or whether MercuryI is throwing the error when it attempts to load.  Testing startup with MercuryI turned off may also be part of the troubleshooting.

I have found this also - it is very important to ensure you start in the correct directory. You can add C:\Mercury to the Path environment variable which will allow you run loader.exe without changing directory within the batch file (assuming there are no other 'loader.exe' files on your system). Regarding the above if your batch file is launched from the C: drive you can simply have cd\mercury and eliminate the C: and cd\ commands. If your batch file is located on a different drive then C: will be required (but I suspect you know all this already).

Adding a cd\mercury command to the batch file before running loader appears to have worked.  Need a couple of more restarts to be totally comfortable but two test restarts went fine.

I report the same problem; an alert pops up

mercuryI Imap server "no such file or directory"

but not when I start Mercury manually.

Normaly I start the loader from a batch file that runs once upon windows login and I solved the problem as indicated above, by first cd'ing into the dir where the loader resides: concretly, here is an excerpt of my batch file:

---------------------
REM Serveur de mails

C:
cd C:\MERCURY\
start C:\MERCURY\loader.exe
---------------

Pb fixed.

JF

Same over here when running M/32 4.8 as limited user.

cd C:\MERCURY
C:\WINDOWS\system32\runas.exe /noprofile /env /savecred /user:Mercury C:\Mercury\loader.exe  --> runs just fine (but needs write access for the user "mercury" to C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp to be able to write MERCURY.INI

whereas
cd C:\MERCURY
C:\WINDOWS\system32\runas.exe /noprofile /savecred /user:Mercury C:\Mercury\loader.exe brings the error described and doesn't load the IMAP module.

HTH, Rainer

P.S. could provide filemon logs if that helped.

edit: 4.7.4 ran just fine using the 2nd line

The Mercury user is a limited user here as well so I don't think that has anything to do with it. Mercury is installed c:\mercury which is also where the mercury.ini file resides.  The Mercury user has full control over that directory.  It is odd that your mercury.ini appears to be in the documents and settings directory of the administer user.  This location explains why you need to overcome access problems to it but I would have expected those problems to have existed on v4.74 as well.

I think we have confirmed that the cause of the original problem was that the batch file HAD to change directory to the location of loader before executing it whereas this wasn't required in versions prior to 4.8.