Hello,

Intermittently, when we delete a ticket that includes an attachment, we get the following error:

IOException: Unable to read resource content
[file name and path]:Unable to delete file

The ticket successfully deletes despite this error, but I assume the attachment is left in place.
This doesn't happen for all tickets with attachments, but it's fairly common. I haven't been able to pinpoint what the differences are for when deleting the attachment fails vs. when it succeeds.

Server information:
osTicket Version v1.16.1 (b42ddc7)
Web Server Software Microsoft-IIS/10.0
MySQL Version 5.5.68
PHP Version 8.0.0

Currently installed and enabled plugins:
Attachments on the filesystem Version 0.3
LDAP Authentication and Lookup Version 0.6.3

I'd appreciate any help troubleshooting this. Thank you!

    jiit

    Sounds like permission/ownership issues on some of the attachment files/folders on the server. I would compare all the permissions/ownership and make sure they all match.

    Cheers.

    • jiit replied to this.

      KevinTheJedi I agree that's how it sounds. Do you know what permissions are required for the filesystem attachment plugin?

      That files that these errors reference have the same NTFS permissions as all the other attachments, which are all inherited from their parent directories.

        jiit

        I believe for folders it is 0755 (or 0751) and for files it is 0644. Maybe it's the user/group ownership?

        Cheers.

        • jiit replied to this.

          KevinTheJedi Hi Kevin,
          You're right, the ownership is different. Some attachments, the owner is the local "Administrators" group. Some, the owner is a local user account that was created exclusively for use by the Task Scheduler for the cron.php job to pull e-mails in. And some attachments are owned by IUSR, which I believe is some kind of default account in IIS (?).

          We don't delete tickets that have attachments very often, so it's difficult to narrow down for sure if certain ownerships are causing the issue. But of the 6 or so I can check, the "administrators" group did not own any attachments that failed to delete. Only the Task User and IUSR.

          I'm not sure how the cron.php task would influence the owner of attachments, or what would determine whether IUSR or anything else becomes the owner. Any ideas?

          (This is a Windows server, btw).

          Thanks!

            jiit

            You’ll need to make sure the cron user is the correct user. Then you can update all incorrect ownerships to the correct one (should be IIS_USR or whatever it’s called).

            Cheers.

            • jiit replied to this.

              KevinTheJedi Hi Kevin,

              What is the "correct" cron user? I did not realize it's supposed to be any specific one. Also, I could manually change the ownership of all existing attachment files to the IUSR account, but the attachments that are failing to delete include ones that already have IUSR as the current owner, so it doesn't look like that would resolve the problem. And, wouldn't changing existing attachments' ownerships still leave the issue of how new attachments are being created with various owners?

                jiit

                I apologize I'm not an IIS expert by any means. I do remember a community member mentioning in a previous discussion that PHP/webserver and the cron job should be running the same user. I cannot remember what the user is supposed to be (I thought IIS_USR) but you should be able to search through the older discussions to see the recommendation.

                Cheers.

                It's been a little bit since I ran IIS, but my recollection was that you need to give permissions to the IIS_USR user on the folder(s).

                Write a Reply...