Change stored images directory

[john (from OnePacs)]

Thanks for helping Damien get on to your system and review things.

It seems what's probably happening is not actually related to OnePacs, but rather has to do with your network file storage system. You are attempting to access it as though it were a local drive with a drive letter, but that isn't actually the case. So basically, this issue has to do with your local hardware arrangements and is not actually a OnePacs issue at all.

Obviously, we can't offer technical support for your local system hardware choices and configuration arrangements, but we can offer advice on where you could go from here based on what we have seen so far. Network drive stores are associated with specific system users and are not generally available to any resource on the system like a real locally attached drive would be. So if you wanted to access a network drive store for this purpose through the OnePacs Gateway, you could try either making the OnePacs gateway service run under the specific user account that has access to the network drive, or use the full UNC path in the file system in the Gateway configuration, rather than the drive letter.

This type of issue is also discussed here:

http://forums.dcm4che.org/jiveforums/th ... start=2050

So basically in summary: The reason you have been having problems storing to your network shared storage drive is because network shared drives are NOT the same as locally mounted real hard drives and in Windows, and you can't use the drive letter path to access them interchangeably like a real local drive. This issue will occur no matter what software package you are using to access them, OnePacs, or otherwise.

I would suggest trying to put in the full UNC path in the gateway configuration, or alternatively you could go into services.msc and edit the OnePacs Gateway service to run under a local system account that has access to the drive. Please check with your local system administrator for further advice because any further than this, we would be getting into the terrain of your local system administration and configuration choices and not really anything OnePacs-specific any more.

Hope this works out, we'd be interested in hearing how it goes.

John

[damien]

A little more info for the casual follower...

The gateway could write to the C: and F: drives fine, but could not write to the I: drive. When the I: drive was configured as the storage destination, there were failures that prevented new studies from being stored. The difference with the I: drive is that it is a drive mapping to network storage.

The reason that the gateway could not write to the I: drive is because the gateway software runs as a system-level service (using the implicit Local System account). A drive mapping to an arbitrary network storage system is a user construct. That drive mapping lasts as long as the user who mapped the drive is logged in. So when the user logged out, the drive mapping did not exist anymore and the gateway could not write to that network location.

In the link that John posted above, pay particular attention to the last comment on the thread by user nuxray. In that post the situation is explained similar to above and some suggestions are offered to make it work. In a nutshell, they involve having the OnePacs gateway run under a user account who has access to that storage location and reference it by the UNC path. nuxray also posted a link to another potential solution on StackOverflow.

-- Damien

[DataTrade]

The saga continues....

I have used the full UNC address for onepacs admin page, added the server to the list of users/computers that have access to the network storage location, set the onepacs gateway service to run as the user account used to map the drive (this administrator account is the same used throughout the network), mapped the drive persistently to the server running onepacs, and performed all previous steps.... to no avail.
(includes setting the new location to RW+ and old to RW, linking the old to the new location, and restarting the service after these changes are applied).

Also, I'm assuming that based on the quoted text below (from the DCM4CHE forum), that the administrator account logon info I gave to the service should be sufficient, considering its the same admin account used to access every machine attached to the network.

That is because network drive mappings are associated with a user and ot with the system. The dcm4chee service normally runs as user LocalSystem (See http://msdn.microsoft.com/en-us/library ... S.85).aspx for more details) and so has not access to any drive mapping. You have to crate a new user say d4c_service and add permission for this user on the network drive. You must add the network path as a UNC path like \\nas\storage\archive and not as a drive letter like Z:\archive.

I'm not sure what else can be done here, but I need to get this working as it is going on month three without a resolution.
If anyone can provide any help, I would appreciate it.

Thanks,

- Brian

[john (from OnePacs)]

We're happy to continue to work with you on this, but for clarification for the record, this is really an issue of your local networking and hardware setup, and would be an issue for your local administrators to troubleshoot. Our recommended hardware configuration would involve locally attached, real physical hard drives rather than virtual drives shared over a network. So your configuration is non-standard and not recommended, and this issue is about how you are setting up and configuring microsoft windows and associated hardware, and it is not a OnePacs issue. Having said that, if you are interested in doing things this way and are interested in our input, we'll be happy to continue to work with you to see if we have any ideas that could help.
If your local administrators do not have sufficient expertise with network storage and the various voodoos that are involved in using this with windows, you also might consider hiring a consultant with expertise in that area to come in and help you with this.