We have common mailbox for our reception team within which we create a folder for clients to securely upload files to us.
We create the folder as the reception user, and generate the Upload link with no expiry date and no password.
The upload link is then provided to our clients and they successfully upload documents to us, with the notification going to the common mailbox.
The documents are processed and then removed.
All good.
However, from time to time, with no apparent pattern, the folder and the upload link disappear, and clients get an error when following the link 
We login again as the reception user, recreate the folder with the same name, and re-generate the Upload link (which is identical to the previous one) and things are again working.
However, this keeps happening and weād like to understand why and how to prevent it.
We need to have a permanently available secure uplink location for clients to send documents.
Can anyone tell us what we are doing wrong?
Thanks in advance,
Matt
Can you try to update to the last version and check if itās ok? I know about some problems on public uploads but I donāt know if itās related.
yum clean all && yum update -y \*webtop5\*
Thanks, we are running the latest version as we keep our system updated weekly.
There was a WebTop update over this past weekend, just after the Cloud folder had again disappeared.
So we re-created the Cloud folder and Upload Link after upgrading to the latest version of WebTop
Although the time it takes to disappear varies, it is usually weeks, rather than days, so I will have to watch for this to happen again and report back here if and when it happens.
Thanks for your help,
Matt
Hi Federico,
The Cloud Folder just disappeared on us again and had to be re-created.
This is the same pattern that has been recurring for many months now.
Tell me if thereās any way I can assist with debug info, etc.
Cheers,
Matt
Hi @Matt1,
check if the username contains the character _
It could be this bug which has already been fixed 
We are working these days for the release of 5.9.5 which will also contain this fix.
BR
Hi Luca,
Thanks for the suggestion, but the username is simply āreceptionā, so itās not that. None of our usernames have non-alpha characters other than ā.ā
Itās also been working fine for uploads for weeks, and then the shared folder simply disappears without warning.
Is there a log of shared folder operations somewhere that I could keep an eye on?
Cheers,
Matt
It just happened again - the link and folder both disappeared and had to be recreated.
This was probably the quickest disappearance weāve had.
Creating the folder in the same place with the same name and then generating the upload link with the same parameters (no password, no expiry) puts it back, but weāre only ever alerted to it by a client who fails to upload a document.
If thereās anything I can do to help debug this, please let me know.
Cheers,
Matt
Hi Matt,
I have done several tests on my installations but unfortunately I cannot replicate your problem 
Where exactly is the shared folder from which you generate the upload link ?
Is it likely that it will be canceled by other transactions ?
Do you find anything useful in the webtop log ? (/var/log/webtop/webtop.log)
Hi Luca,
Intermittent bugs are always difficult to replicate 
The folder is the only folder under the top Documents folder in a shared mailbox in the WebTop Cloud. Itās accessed by a team of people via WebTop sharing, and they have permissions to delete files from the folder once processed.
Originally I thought it was someone accidentally deleting the shared folder, but itās happened often enough, and the team has incurred enough āre-trainingā that Iām now very confident that is not the case.
So the use cases are very few and simple once the folder is created and the public, non-expiring upload link generated :-
- upload link shared to lots of clients via email
- clients upload document (mostly PDF, but sometimes JPG or other)
- the shared mailbox receives an email notifying them of the new file
- team member downloads that file and puts it into our DMS
- team member deletes that file from the WebTop cloud folder, leaving the folder empty
At your suggestion I looked into the webtop.log file and I think I may have found an exception around the time it probably happened. I will need to dig up the old logfile from the last time it happened and see if I can find similar there too.
Hereās the exception, which was thrown around 15 minutes after the last recorded upload to that folder, so probably around the time the team member was removing that file. We were alerted to the folder having disappeared about 90 minutes after the exception when a client tried to upload a file and the folder was gone. So it looks to me like the except was generated at the time of processing the last file, not when a client tried to upload a new file.
2020-11-26 19:10:15 [ERROR] com.sonicle.webtop.vfs.Service - Error in ManageStoresTree
java.lang.NullPointerException: null
at java.util.Arrays.sort(Arrays.java:1438)
at com.sonicle.webtop.vfs.VfsManager.listStoreFiles(VfsManager.java:639)
at com.sonicle.webtop.vfs.Service.processManageStoresTree(Service.java:435)
at sun.reflect.GeneratedMethodAccessor658.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.sonicle.webtop.core.app.servlet.BaseRequest.invokeMethod(BaseRequest.java:109)
at com.sonicle.webtop.core.app.servlet.PrivateRequest.processRequest(PrivateRequest.java:86)
at com.sonicle.webtop.core.app.servlet.PrivateRequest.doGet(PrivateRequest.java:113)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:634)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:741)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:231)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:61)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AdviceFilter.executeChain(AdviceFilter.java:108)
at org.apache.shiro.web.servlet.AdviceFilter.doFilterInternal(AdviceFilter.java:137)
at com.sonicle.webtop.core.app.shiro.filter.GZip.doFilterInternal(GZip.java:60)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.shiro.web.servlet.ProxiedFilterChain.doFilter(ProxiedFilterChain.java:66)
at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:449)
at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:365)
at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90)
at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83)
at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:383)
at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilter.java:362)
at org.apache.shiro.web.servlet.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:125)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:199)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:543)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:747)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:615)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)
Iāll go looking for the old logfile too.
Let me know if thereās anything else I should look for.
Thanks again for your help with this,
Matt
Ok Matt, thanks so itās much more detailed
Iām afraid someone from the development team needs help: @matteo.albinola and @gabriele_bulfon do you have any idea what the problem might be from what the log reports ?