DanHLJr

You need to find a replicable case and see how exactly they are uploading, what they are uploading, etc.; essentially exact steps to replicate. You can also look at the Network tab in the browser's developer tools for the failed request and see what error it gives you. You should also have the people who can replicate try on a new browser with no browser extensions, etc. as the extensions can sometimes cause issues as well. You should also ensure you don’t have "Bind Agent Session to IP" setting enabled as this can sometimes cause session issues. You should also try increasing the Agent and User session timeouts in the system settings.

Cheers.

    Thanks Kevin!

    I've disabled the Agent and User timeouts. (We actually have no users that aren't agents. Everything on the front-end is pretty much dead/disabled. We do email-only support.)

    Unfortunately, it's not something I can easily reproduce. These are end-users in other locations reporting stuff after-the-fact. It's all completely intermittent, and honestly only happens rarely - I haven't seen it happen in person, but it happened today with a single user 3 or 4 times in a row, and that pretty much panicked everyone. (This is a trusted, competent user here, so we know what they are telling us is true.)

    The human challenge here is that, "This doesn't happen with other systems." So these users are experiencing a failure that they DO NOT experience with any of the other systems they use daily.

    I don't know what to say. I hope this session timeout thing fixes it. (And if it does, you should probably look into why it's happening with limited session timeouts...definitely a software issue in that case!)

    A thought/note: We previously had a different timeout for User sessions than Agent sessions. The Agent timeout was longer. Could something regarding attachments be related to the user timeout? Like the Agent still has the session, but the attachment is tied to User timeout, so it fails??? (I say this, because when I tried to "close" the front-end by limiting User/front-end portal to only a certain IP through Settings, it did indeed BREAK attachments for Agents on the backend trying to download...they could not access the attachment URLs because the front-end was blocking their IP.)

    It does seem that the system has at least that know issue, where agents should have been able to access attachments regardless of the front-end being "locked".

    I hope this helps...

      DanHLJr

      That’s because all file URLs point to the files.php file. You should’ve added an exception for this file for attachments to work for Agents.

      User sessions are only tied to Users and are completely separate from Agents.

      We have reports of session issues which we are actively looking into.

      Cheers.

          Thanks for the heads-up on needing an exception for the files.php when blocking the front-end by limiting IPs. Look forward to hearing a solution on the session issues, which hopefully resolves the problem with file attachments occasionally just getting "lost" when replying to tickets. (EDIT: Adding, "In the meantime, I've just disabled session timeout - set to 0 - to see if that resolves it, at least temporarily.")

            a month later

            DanHLJr
            Have you had any more errors after configuring session timeout to 0? I have also been getting reports of this issue happening randomly.

              a month later

              KevinTheJedi Wanted to let you know that I configured agent session timeout to 0 on 18.12.2023 and since then no errors have been reported to me.

                17 days later

                FYI, we are experiencing this too.
                Attempting the Agent Session Timeout = 0 now, it was previously set to 43830.
                We have multiple agents having this, its intermittent, we use firefox,

                osTicket Version 1.18-git
                Web Server Software Apache
                MySQL Version 10.6.16
                PHP Version 8.2.15

                  hsaartet

                  I would recommend three things:

                  1. Make sure you are using the latest, officially packaged version of osTicket from our website.
                  2. Make sure you have the latest Filesystem plugin installed.
                  3. Check your PHP and webserver settings to ensure your max post size, etc. are adequate enough.

                  Cheers.

                      KevinTheJedi

                      PHP settings are good, we have been using OSTicket for years no problem.
                      We do have our own mod's in it but nothing major.
                      Just checked we have the latest branch merged on git.
                      At best estimate we think it might have started around about the time we merged in
                      https://github.com/osTicket/osTicket/commit/3dd2ed35f3bfd2f061f46395b5a863b40c3f97a9
                      or
                      https://github.com/osTicket/osTicket/commit/4689926b2d3d25754f0ddcf8d4e181a2817f6d56

                      Hopefully this helps, i'll test the agent sessions = 0 and see if we have more issues, but might take me a week to say either way

                          hsaartet

                          Well none of those commits relate to attachments so those are not it. Unless you mean when you merged up to those commits.

                          Cheers.

                              Hi Kevin
                              I'm not a developer by any means, but you noted above about 'agent sessions' and such and i note there is a commit
                              https://github.com/osTicket/osTicket/commit/2b5fa48590cff705e38aaeb9c77d42d7980cc73c

                              which seems to change the way sessions are handled.

                              This is intermittent, so its gonna be hard to track down, but once i have finished the agent session timeout experiment, I'll try another reversing that commit unless you can think of anything terrible about that idea.

                              Regards

                                hsaartet

                                This would only affect a system that is using the SystemSessionHandler. Your system should be using database session storage which is AbstractSessionHandler.

                                This commit was added to continue to allow systems on 1.6.x (released circa 2009) to be able to upgrade to the latest releases. You see, 1.6.x didn't have the concept of database session storage; this was introduced in later versions. So when you are upgrading from 1.6.x to the latest your 1.6.x database won't have the proper session tables so you still need to use the system session storage until the upgrade is complete. Once upgrade completes then it switches to using the database storage which is the abstract session storage backend.

                                You can see where we set system or the configured backend in the config file or default to database here:

                                All that to say I really don’t think this is the cause of your issue.

                                Cheers.

                                  17 days later

                                  So, we tried the 'Agent Session Timeout = 0 now, it was previously set to 43830.' option and this has not fixed it.

                                  Any further ideas on this,

                                  As mentioned the core issues is agents attaching files to posts, hitting reply and the attachment is gone and doesn't send, they can immediately repeat this and it works fine 2nd time.

                                    hsaartet

                                    That definitely sounds like session issues then. After work hours, TRUNCATE the entire _session table. It's important to do this after-hours as it will kill any active sessions. Once you truncate the table you can have your Agents completely clear their cache/cookies, log in, and retest.

                                    Cheers.

                                      Hi Kevin, thanks for the help, the issue is extremely intermittent.
                                      We only have 7 users and really only attach files 2-3 times a day, we might get a fault once or twice a week.
                                      Should we be looking at truncating that table nightly? or once off?
                                      Regards

                                        hsaartet

                                        You should have a cron job configured so the system will routinely clean expired sessions. This happens on auto-cron too (I believe) but will happen way more seldomly than a reoccurring cron job.

                                        Cheers.

                                          We have httpdocs/api/cron.php running every min..... should we have anything else?