ERROR - Failed to open file

[Jonathan]

Code: Select all

Mon Jul 31 13:18:23 2006 INFO - <7033> C-STORE [15] command received in P-DATA-TF PDU
Mon Jul 31 13:18:23 2006 DEBUG - Running SQL Query: SELECT tag,syntax FROM coercion WHERE aetitle='CT2N' ORDER BY sequence ASC;
Mon Jul 31 13:18:23 2006 ERROR - Failed to open file [//cas1/dicomarchief/2006_5/1.3.12.2.1107.5.1.4.49358.30000006060607251396800001115] for SOP instance: 1.3.12.2.1107.5.1.4.49358.30000006060607251396800001115
Mon Jul 31 13:18:23 2006 DEBUG - <7033> 156 bytes PDV read from P-DATA-TF PDU [156]

Server specs:
OS: Windows 2000 SP4
CPU: dual 2.8 GHz Intyel Pentium 4 XEON
RAM: 2048 MB
MySQL: 4.0.22-nt-max-log

I found above in my log files today and cannot understand why the PacsONE service cannot find the file as it is there and can be accessed as user from the server where PacsONE is running.

The PacsONE service is running as a separate member of our domain with the correct security settings to access the remote share on our archive system.

The only thing I can think of is that our PacsONE server is running at a Windows based server and in the path that is quoted in the log file forward slashes are used to display directory separators. Can it be that the program uses the wrong directory separator internally as I have changed the forward slashes to backward slashes for it to work when I try it manually?

[pacsone]

Mon Jul 31 13:18:23 2006 ERROR - Failed to open file [//cas1/dicomarchief/2006_5/1.3.12.2.1107.5.1.4.49358.30000006060607251396800001115] for SOP instance: 1.3.12.2.1107.5.1.4.49358.30000006060607251396800001115

This error means PacsOne could not open that path for writing the received Dicom image, so you need to make sure the user account PacsOne Server is running under (default is the Windows built-in SYSTEM account) has sufficient permission settings to write to this remote path:

Code: Select all

//cas1/dicomarchief/2006_5/

on this host cas1.

[Jonathan]

This error means PacsOne could not open that path for writing the received Dicom image, so you need to make sure the user account PacsOne Server is running under (default is the Windows built-in SYSTEM account) has sufficient permission settings to write to this remote path:

Code: Select all

//cas1/dicomarchief/2006_5/

on this host cas1.

That is exactly what I have done:

The PacsONE service is running as a separate member of our domain with the correct security settings to access the remote share on our archive system.

To write on the remote host we have created a domain member. The pacsone service runs under this account and not under the build in system service account (as that account is not allowed to browse the network). The system can write images at this remote location. It has done for a few years and still does for a multitude of GB's per day.

I can also open the specified image on the remote from the server where PacsONE is running using other software so I'm quite sure that this is not the problem, but I hope you can help me solve this problem.

[pacsone]

Does this error occur for all received images from this source AE, or just this particular image?

1. If the error only occurs for this particular image while other images can be stored fine under this remote path, then you can rule out the security permissions as the potential source of this problem, as other images can be writen to the same remote path. The next thing to check is if there is any other application (e.g., Apache) which is holding on to the file handle of this particular image, which was preventing PacsOne Server from writing to that file. If you stop that application, and this error disappears, then it means that application was not releasing the file handle thus caused the Write error to that image file.

2. If the error occurs for all images to be stored under this remote path, it still seems to be a security permission issue. You can try assigning a different remote pathas the Archive Directory for this source AE, e.g.,

//cas1/dicomarchief/2006_7/

and see if images can be saved successfully there. Or change the user account PacsOne Server is running under to a local Windows account on this host cas1, e.g., Administrator, and see if the same error occurs. Hopefully, one of these different settings may shed some light into where the problem is.

[Jonathan]

Does this error occur for all received images from this source AE, or just this particular image?

1. If the error only occurs for this particular image while other images can be stored fine under this remote path, then you can rule out the security permissions as the potential source of this problem, as other images can be writen to the same remote path..

It can still store other images received from several other modalities.

The next thing to check is if there is any other application (e.g., Apache) which is holding on to the file handle of this particular image, which was preventing PacsOne Server from writing to that file. If you stop that application, and this error disappears, then it means that application was not releasing the file handle thus caused the Write error to that image file

That could be part of the problem, but I think highly unlikely (I was trying to query a remote CT from the device through the web interface and I am sure I was the only one there as the webserver is configured to listen only to localhost requests). I will try to send it again from the modality after disabling Apache as querying is not possible without a webinterface.

2. If the error occurs for all images to be stored under this remote path, it still seems to be a security permission issue.

That is certainly not the case, other files (+800MB) have succesfully been written there since the error occured.

[pacsone]

You may also want to check if there is something else (e.g., other viewers) which was accessing the same image files (and was not releasing them after use) when the error occurred.