Fatal: `Sabre\DAV\Exception` Could not rename part file to final file

[maltepost]

We get "Could not rename part file to final file"-Errors when trying to write files in shared folders in a group folder (group folder/shared folder/...) on two different servers which were updated to version 21.0.1.1. The two backup servers with version 20.0.9 run fine. Any ideas?

[webdav] Fatal: Sabre\DAV\Exception: Could not rename part file to final file at <<closure>>

0. /var/www/nextcloud/apps/dav/lib/Connector/Sabre/Directory.php line 156
   OCA\DAV\Connector\Sabre\File->put(null)
1. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 1098
   OCA\DAV\Connector\Sabre\Directory->createFile("210412_CDD Proj ... X", null)
2. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/CorePlugin.php line 504
   Sabre\DAV\Server->createFile("Testuser.docume ... X", null, null)
3. /var/www/nextcloud/3rdparty/sabre/event/lib/WildcardEmitterTrait.php line 89
   Sabre\DAV\CorePlugin->httpPut(Sabre\HTTP\Request {}, Sabre\HTTP\Response {})
4. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 472
   Sabre\DAV\Server->emit("method:PUT", [Sabre\HTTP\Requ ... }])
5. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 253
   Sabre\DAV\Server->invokeMethod(Sabre\HTTP\Request {}, Sabre\HTTP\Response {})
6. /var/www/nextcloud/3rdparty/sabre/dav/lib/DAV/Server.php line 321
   Sabre\DAV\Server->start()
7. /var/www/nextcloud/apps/dav/appinfo/v1/webdav.php line 84
   Sabre\DAV\Server->exec()
8. /var/www/nextcloud/remote.php line 167
   require_once("/var/www/nextcl ... p")

PUT /remote.php/webdav/Testuser.documents/210412_CDD%.DOCX
from 62.84.220.XXX by Testuser at 2021-04-19T10:19:58+00:00

[JacoboDominguez]

Same problem, it seems an issue with the folder path, the error reports access to the path:
./data//
while in the server group folders are inside the ./data/__groupfolder//, e.g.
./data/__groupfolder//

I fixed temporally creating a symbolink link in ./data/ => to the ./data/__groupfolder/
Is this a bug with the code or should this symbolics link be created?. The symbolic link is a temporary fix for me, because group folder name could collide with an username, that must be the reason to host them in the __groupfolder.
Cheers

[propcoder]

I met similar issue and reported here: github.com/nextcloud/server/issues/26649#issue-862649435

[variantolog]

Same problem. Servers with version 20.0.9 run fine.

In my case:
/mnt/ncdata/__groupfolder/4 - Group folder (with ID 4)
/mnt/ncdata/__groupfolder/4/FSFU - Folder shared for user (located in group folder with ID 4)

User tries to upload own files in FSFU
Error in log: unable to rename, source directory is not writable : /mnt/ncdata/FSFU
In fact, of course, there is no such folder at all

My temporary fix: ln -s /mnt/ncdata/__groupfolder/4/FSFU /mnt/ncdata/FSFU

[variantolog]

P.S.
IMHO, i assume that when forming the full path, instead of the getSourcePath() function from the GroupMountPoint class, some other function is used.

[kaberdouch]

Same problem after migrating to docker and upgrading from 20.0.8 to 21.0.1

[HLeithner]

same problem here Nextcloud 21.0.1

[N4IR0]

It seems that this bug also exists after upgrading to Nextcloud 20.0.9

[bob4os]

Interestingly moving a file from your Nextcloud root folder into your shared subfolder of a groupfolder is possible.
Permissions on the share do not matter.
(PHP 7.4 and Lighttpd)

[borekon]

Same problem. Servers with version 20.0.9 run fine.

In my case:
/mnt/ncdata/__groupfolder/4 - Group folder (with ID 4)
/mnt/ncdata/__groupfolder/4/FSFU - Folder shared for user (located in group folder with ID 4)

User tries to upload own files in FSFU
Error in log: unable to rename, source directory is not writable : /mnt/ncdata/FSFU
In fact, of course, there is no such folder at all

My temporary fix: ln -s /mnt/ncdata/__groupfolder/4/FSFU /mnt/ncdata/FSFU

Same here, except if i create a file instead of upload it, the file is created in the right folder and no error is shown

[ornanovitch]

It seems to be a duplicate of the recent #1445 (or at least linked to it)

This might affect a lot of users...

[HLeithner]

Many things have been fixed in 9.0.1 but not this issue (at least for me)