How to address repeated “Path/File access” errors

First we ask you to please understand, if you are in this situation, it very much needs to (and positively SHOULD) be addressed. Absolutely, this is NOT a situation you should consent to continue living with.

Second, we hope you will accept that the situation does not result from any fault in Rossware systems.* Rather, it results when Rossware systems are attempting to access (for either read or write purposes) data that’s maintained on your server, and when (for whatever reason) your system is not appropriately providing access to that data.

You may wonder why (if the fault is indeed not in ServiceDesk and is instead owing to some fault in your system) do you not similarly see errors in other applications you are running? It’s a very valid question, and has an equally valid answer. It’s very likely you are not running any other application that involves a very large data set that multiple stations are simultaneously (and real-time) managing. Where you have this particular and unique dynamic, it’s essential that your system allows each station instant and perfect access to each underlying data file, without exception and literally many thousands of times throughout each day (none of your other apps requests access with anything even approaching such frequency).

Even if your system fails with only one out every several thousand such data-access requests, you will see somewhat frequent “Path/File access” errors in ServiceDesk. With any other application, any such showing would be a super-rarity. The bottom line is that, much more than most apps, ServiceDesk (and other Rossware system too) depend much more on your networked system working flawlessly.

Based on this, if you are indeed encountering repeated though random and somewhat frequent Path/File access errors, it’s apparent your networked system is performing less perfectly than needed. Very likely, this imperfection is caused by one of four situations (where the guilty culprit is, obviously, manifesting itself only but intermittently): (a) there is some process running in your system that’s causing occasional interference with needed communication (e.g., virus protection software, backup systems, etc.); (b) there is a direct fault in your network communication; (c) there is a fault in the server itself; or (d) there is a fault in one or more client stations.

To find the actual cause and remedy, we recommend pursuing a strategy in sequence (i.e., do each step in order, not proceeding to the next step unless preceding steps failed to produce a solution) as follows:

To be very clear on this, if you are getting the error in precisely the same context every time (in other words, each and every time the message indicates it’s the same procedure and/or underlying file where access has failed), then it may indeed be owing to a fault in the underlying program code of ServiceDesk or of another Rossware system. However, where the error arises sometimes in one context and sometimes in another (i.e., randomly), it follows the fault must indeed be in your system, and can only be solved by a correction from within your system.

1. Seek to assure you have eliminated any process that might potentially be causing the symptoms. For example, see what virus protection systems are running (in general, we recommend using only malware-protection software per install; it’s because sometimes multiple systems will fight against one another), and generally we prefer to see use of the free software, as opposed to use of any third-party system (please be aware that even after having been ostensibly “uninstalled” some malware protection systems leave remnants remaining, and it may take special efforts to find and remove such remaining elements). Similarly (in regard to theserver and each station as well), look to see what backup systems are running. We have especially seen that backup systems frequently interfere with internal processes.

2. Change out the Ethernet cable that connects between your server and switch (potentially use a different physical port within the switch as well). Sometimes, an issue like yours can be triggered by nothing more than an intermittently bad cable and/or intermittently bad port within the switch. (Hint: this assumes the issue affects all stations in your network; if it affects only a particular station, change out that station’s Ethernet cable and connecting port).

3. Change out the Ethernet adapter in your server (ditto re hint above).

4. Assure you have but a single router and single switch (sometimes multiple switches in a single network configuration will cause conflict issues).

5. Change out your switch.

6. Change out your router (please note your switch and router may be configured as a single/combined unit).

7. Selectively disconnect each station from connection to the network. By “selectively,” what we mean is first disconnect Station 1, and see if symptoms persist. If symptoms do persist then reconnect Station 1 and disconnect Station 2, and see if symptoms persist,etc. If you find that removal of any particular station solves the issue, then you will know the fault is at that station (i.e., it is messing up network communication for all) and you can then proceed to replace its Ethernet cable, then its Ethernet adapter if replacement of the Ethernet cable did not solve the issue, etc.

8. If you still have not found a solution, it’s possible that more than one station in your system is interfering with consistently-perfect network communications. Try disconnecting half the stations and see if the remaining half purrs happily. If that fails, try disconnecting the other half. If/when you find that a particular set of disconnections solves the issue, seek to narrow down within that set.

9. Try using a different server (it is possible, for example, your server may be encountering occasional communication faults with its own hard drive).

Please recognize that, as each above-described step is concluded, you will need to allow a bit of real-time use to see if the symptom persists, or has been ameliorated. Depending on how frequently the symptom has typically been expressing itself, you may need to allow ore or less time of post-change real-use, to see if the change truly did make an authentic difference. When you find a change that truly makes the needed difference, you may then say “Eureka, I nailed it,” and proceed in happy bliss going forward.