RCs of 27.1.0, 26.0.6 and 25.0.11

Maintenance releases of 26.0.6 and 25.0.11 are coming next Thursday and RCs for those are now available on our download server. Also available is the second RC of 27.1.0!

As always, help with testing is very much welcome!

We updated our servers, did our tests, and the release candidates seem pretty decent. Still, give it a whirl and report back here so we’re even more sure that it’s good to go! If you notice anything out of order, please report back on the appropriate github repository! :bowing_woman:

Downloads

Changelog

27.1.0rc2

26.0.6rc1

25.0.11rc1

2 Likes

Installed 27.1.0 rc2 on my test system, and it seemed to go well. I updated from rc1.

I’m having an odd problem with group folders on my production system (27.0.2) with intermittent “file no longer exists” errors. The problem occurs occasionally, and on a single file it will persist for a while (say 10 seconds maybe) and then go away. (Apparently this is only for group folders, and I have quite a few files on my production system in group folders.) I’m hoping 27.1.0 might help fix the problem, so I’m anxious to try the release on my production system.

Please check whether you can find a similar report on the groupfolder’s bug tracker: Issues · nextcloud/groupfolders · GitHub

If not, it would be great to open a bug report with clear reproduction steps so the developers can investigate.

1 Like

Yes, thanks, though I’d like to make a reproduction recipe, but I can’t get it to happen in my test installation.

I also tried temporarily applying RC2 to my production system, but it did not solve the problem. I also tried disabling most of the apps in the production system, but that did not solve the problem either. I wonder if it might be a PHP version issue, as I’m using the latest PHP 8.2; I suppose that’s another thing I could try to change – edit: nope, changing to the latest 8.1 did not clear up the problem either. I’m using FPM, as recommended … maybe I should switch back …

I figured out how to increase the logging to debug level, and I can see an error happening, but unfortunately it’s not really very specific. Below is an excerpt of the error. But again, I’m not sure if it’s worthwhile to file a formal report yet when the behavior is so vague.

Also, I did can get the problem to happen with a collectives sub-tree while looking via files (though the stack trace is slightly smaller), so I guess it’s not 100% related just to group folders.

Additionally, I find that I can interrupt the condition if I access the root directory – for instance, open a new tab to the root of the files. I tried this because it seems that it will always have trouble finding the top directory in the tree (although with Collectives it’s the second level directory – the one just under Collectives – and when this happens, if you don’t go back to the root, none of the collectives show up in the files app in the browser). Unfortunately, I haven’t triggered the condition on my test installation yet.

And: It seems that the problem will persist until the browser ends up at the root. If a directory is clicked and the error occurs, you’re automatically placed at the root. Another thing I can do to free the problem is to click the notes categories. If the system isn’t jiggle a bit like that, the problem seems persistent. So, ultimately it seems like the root directory needs to be cached or something. After a short timeout (not measured; maybe a minute?), the cache is lost, and subsequent file open operations fail until the root is re-cached. But this does not occur for normal user files, and accessing other user files doesn’t refresh the root cache. But Group Folders and Collectives both show this problem in a somewhat similar fashion, although accessing Collectives via the app (not files) works fine.

I created a shell script to read the contents of the root directory and the Collectives directory every 10 seconds. That seems to solve the problem, but it appears to work on a per-user basis, so I’ll have to create a script for every user on the system (including creating an app password for each user on the system to use in the script). Seems like a pretty bad hack, but I don’t know what else to do right now. I think the problem might be related to some setting I’m using, but I can’t think of anything to try.

  Debug    webdav             Sabre\DAV\Exception\NotFound: File with name //MCF could not be located at                      2023-09-09T20:36:01+00:00 
                              apps/dav/lib/Connector/Sabre/Directory.php line 227                                                                       
                                                                                                                                                        
                               0. .../sabre/dav/lib/DAV/Tree.php line 78                                                                                
                                  OCA\DAV\Connector\Sabre\Directory->getChild(                                                                          
                                                                                                                                                        
                                  )                                                                                                                     
                               1. 3rdparty/sabre/dav/lib/DAV/Tree.php line 73                                                                           
                                  Sabre\DAV\Tree->getNodeForPath(                                                                                       
                                                                                                                                                        
                                  )   

...

                              14. apps/dav/appinfo/v2/remote.php line 35                                                                                
                                  OCA\DAV\Server->exec(                                                                                                 
                                                                                                                                                        
                                  )                                                                                                                     
                              15. remote.php line 172       

Mh, that is odd. Did you double check the permissions on the file system, whether the web user can actually access the files in the datadir?

Yes, they’re all owned correctly. And operation seems fine until I leave the tab for a bit and then try to access a file. Often times, I can just surf to the file and open it before the problem happens. Also, when a directory has the error, it puts me back to the root, which then reset the cache or whatever and made things work for a while again.

I guess I might want to try backing out some of the optimizations I did, but I’m not very confident that doing it will eliminate the problem.

I opened a ticket #2547, but since this doesn’t seem to be a typical problem, I think I’ll be on my own in trying to fix/diagnose it. Unfortunately, until then, I kind of have egg on my face (as I am a promoter of Nextcloud in my organization).

Thanks for filing the issue. What might be also relevant: which user and group backend do you use?

Generally, groupfolders are not releases together with server/hub.

Ah, OK. Yes, I’m using the “default” (?) user creation and maintenance, but I’m considering LDAP on one of the installations at some point.

Then, I would not expect surprises, that’s the most straight forward backend with direct control.

Hmmm, I’m getting a slow proxy response? I’m not sure why tho? Internet is half decent speeds, VMware guest is well spec’d and decent ram etc also my Nginx proxy is well spec’d

Fyi “RC4”

Edit 18th September: Hmmm the update somehow was applied?

Thanks