Unable to access remote UNC paths using service w\ v6.0.18

[MeInMaui]

I just upgraded my server and client to 6.0.18 a couple of days ago. I am running the service on the server with a password protected administrator account. Since the upgrade I am no longer able to access UNC paths on the client through SageTV. UNC paths that reside on the server are still accessed normally. If I disable the service and start SageTV in application mode then the remote UNC paths are accessible again. I am running WinXP Home on both systems. This worked before the upgrade. Has anyone else seen this? Any suggestions? I just wanted to check here before filing a bug report. Thanks!

Aloha,
Mike

[GKusnick]

Did you reconfigure SageTVService after the upgrade? The installer typically resets the service to use the LocalSystem account instead of whatever account you had configured before, so you need to manually reconfigure that each time you upgrade or reinstall.

[MeInMaui]

Originally Posted by GKusnick

Did you reconfigure SageTVService after the upgrade? The installer typically resets the service to use the LocalSystem account instead of whatever account you had configured before, so you need to manually reconfigure that each time you upgrade or reinstall.

Yes I did reconfigure the service. I just checked again to make sure and it is set to use the password protected account. Thanks.

[jlabrue]

Hey Mike,

What type of "password protected administrator" account are you using? Is it a local administrative account or a Windows domain type administrative account? I have a similar setup to what I think you are describing and the service/client are working for me on all the 6.x versions. I do use a domain account though. I run the service with a domain account and logon to the server and client with the same domain account and I use only UNC paths to my recording/import directories. My first thought is it probably isn't a bug but maybe the remote path methods have changed some how in the new version. Happy to give you more detailed info on my setup if you think it will help.

[MeInMaui]

The account is just a local account with administrative privileges. I'm not running a domain. I have full access to the network shares in question. Sage just doesn't see them.

[jlabrue]

I know your a sharp guy so you have probably tried most everything I would have. I doubt the domain issue is relevent, it is just what I have. All my recordings are on a seperate box using UNC paths. My client and MVP's don't have any problems but I am logged in as a domain account with access to the share and the service is running under that same account.

Are you logged in with the same account that the service is running under? I would think is you were, you wouldn't see any difference in service mode or not. If you aren't then it may be running under a different context. Are you also running the server as a client as well?

[MeInMaui]

Originally Posted by jlabrue

I know your a sharp guy so you have probably tried most everything I would have. I doubt the domain issue is relevent, it is just what I have. All my recordings are on a seperate box using UNC paths. My client and MVP's don't have any problems but I am logged in as a domain account with access to the share and the service is running under that same account.

Are you logged in with the same account that the service is running under? I would think is you were, you wouldn't see any difference in service mode or not. If you aren't then it may be running under a different context. Are you also running the server as a client as well?

Well, apparently I'm not the sharpest tool in the shed. I wasn't logged in with the same account the service was using. Once I did that, everything was fine. Thanks!

[jlabrue]

Great, I'm glad your working again. Makes me wonder how Sage is using the security principles in authentication and if it has changed slightly. In theory, you should be able to run the service as an account that has access to a remote share and login with a different account, possibly a limited account, and all should be well but we just disproved that theory. It seems to be using the logged in user account rather than the account the service is logged in with. I'm changing my thinking on this and I would be inclined to think this IS a bug now worth reporting.