Hi All,
I got these exceptions generated pretty much every 10-20 minutes or so, pretty random.
This has started since I re-enabled the cron job for monitoring the mailbox.

(root)/st0rag3/Z/ZWUjaczE6xvCbybnyBmmeIgsx8Ymm2EA: Unable to delete file

#0 (root)/include/class.file.php(151): FilesystemStorage->unlink()
#1 (root)/include/class.file.php(685): AttachmentFile->delete()
#2 (root)/include/class.cron.php(51): AttachmentFile::deleteOrphans()
#3 (root)/include/class.cron.php(118): Cron::CleanOrphanedFiles()
#4 (root)/include/api.cron.php(19): Cron::run()
#5 (root)/include/api.cron.php(40): CronApiController->run()
#6 (root)/api/cron.php(23): LocalCronApiController::call()
#7 {main}

I think this is some issue coming from legacy configuration.
Currently the attachments are set to be stored in the database not the filesystem but at one point I changed that to filesystem. Not sure if there are some old tickets that are upset this has been flipped back to the database.
Best regards

  • KevinTheJedi
    I checked the example above and the file is not there.
    What I did I just renamed the old dir and let the software recreate the sub-directories in the fresh dir what it did.
    The errors have ceased since then.

    This cron is executed every 2 minutes.
    In cron report I receive every 2 minutes I can see this line:

    Deprecated: Directive 'allow_url_include' is deprecated in Unknown on line 0

    Not sure if this can have any impact on the above issue that happens with much less frequency.

      VerusAutenticus

      Cron is running which triggers the cron scripts. One of the cron scripts deletes orphaned files (files that don't belong to anything in the system). The system is trying to delete an orphaned file however is failing. Probably due to permissions. You need to make sure cron is running as the webserver user and make sure all the files/folder of the attachment directory are owned by the webserver user/group. Once you do this the system should be able to delete the files.

      Cheers.

          KevinTheJedi
          ok however since I changed to database shouldn't this just stop attempting to delete these files I mean ignore them?
          Or is it because the tickets that have attachments that happen to be saved in the filesystem storage at the time are now complaining.
          I changed this filesystem to database months ago but it only started complaining a lot when I added that cron job what seems unrelated.
          I checked the permissions and all the files belong to my user.
          The main filesystem storage directory is 775 while subdirectories (alphabet letters and numbers) are 751 while the hashed files themselves in them are 644.

          The cron job is as follows. This is the only valid way:

          */2 * * * * /usr/local/bin/php80 /home/USER/domains/DOMAIN/public_html/api/cron.php

          This is the only cronjob in crontab.
          Should I maybe flip back to filesystem storage? I think at the end it should be more efficient than database.

              VerusAutenticus

              It's trying to delete old files that were stored on FS back when you had it enabled.

              Change your cron job to:

              */2 * * * * webserver-user /usr/local/bin/php80 /home/USER/domains/DOMAIN/public_html/api/cron.php

              ... and replace webserver-user with the actual webserver user (eg. apache2, httpd, etc.).

              Should I maybe flip back to filesystem storage?

              This is up to you; whatever you want to do as it's your setup.

              Cheers.

                  VerusAutenticus

                  From the error message it seems the user running the script doesn’t have enough permissions to delete the file. I guess we should first check if the file actually exists. Go to the path in one of the errors and see if the file it’s complaining about actually exists. If so, check the file's ownership.

                  Cheers.

                      KevinTheJedi
                      I checked the example above and the file is not there.
                      What I did I just renamed the old dir and let the software recreate the sub-directories in the fresh dir what it did.
                      The errors have ceased since then.

                        Write a Reply...