path issues with group folders?
Server
Operating System: Debian 10 (buster) Web Server: Apache/2.4.38 Database: mariadb Ver 15.1 PHP: 7.3.19 Nextcloud: 19.0.4
Client
Operating System: Windows 10 Pro (1903) Nextcloud Client: 3.0.2
Error
I am getting the following error message (100+ times) on the server side:
[core] Error: unable to rename, source directory is not writable : /nextcloud_data//some_folder/some_folder/some_folder
MOVE /remote.php/dav/files/user/some_folder/some_folder/some_folder/some_folder
from 123.123.123.123 by user at yyyy-mm-ddThh:mm:ss+00:00
the corresponding error on the client:
**# timestamp:**
**duration:**
**file:** some_folder/some_folder/some_folder/some_folder -> !__some_folder/some_folder
**instruction:** INST_RENAME
**dir:** Up
**modtime:** >>removed<<
**etag:** >>removed<<
**size:** 0
**fileId:** >>removed<<
**status:** 2
**errorString:** Server hat "403 Forbidden" auf "MOVE https://>>nextcloud<</remote.php/dav/files/user/some_folder/some_folder/some_folder/some_folder" geantwortet
**http result code:** 403
**other size:** 0
**other modtime:** 0
**other etag:**
**other fileId:**
**other instruction:**
i replaced sensitive information with dummy values or >>removed<< it completely
I am assuming there is some issue with the path that is not writeable because it does not exist. All the folder permissions for /nextcloud_data/ and it's sub-folders should be correct and are working for other users, and are working for all of them when the web interface ist used.
what the path looks like: /nextcloud_data//some_folder/some_folder/some_folder
what i guessthe path should look like: /nextcloud_data/__groupfolders/groupfolder_id/some_folder/some_folder/some_folder
Thanks for your support!
You give the logs, thanks for it.
But coule you explain, from a user perspective what you were trying to do, what happened, and what did you expect? Thanks
But could you explain, from a user perspective what you were trying to do, what happened, and what did you expect? Thanks
Any word @LukasReithofer? I'm going to close this out since it's stale and further details weren't provided after 3+ years. As a result we lack sufficient information to reproduce or isolate cause.
If new information comes in and this issue is still occurring, we can always reopen.
As this installation was a kind of critical one, which had to be back up as quick as possible, i decided on dropping the groupfolders app. As there was no way of turing groupfolders back into regular folders, i hacked together some shellscript to move the groupfolders back to regular user folders and share them that way, which did solve the problem.
Due to customer concerns, nda etc. i am not able to share that work at this point in time, but if someone would be interested i could redo that "get rid of groupfolders without users having to resync" script and share it here. Basically it moves and renames the main folder and applies the changes to the database, still maintaining all the shares of course.
Same issue. Any progress?
@Durkar No. As noted we need a a way of reproducing the matter and context from your environment like NC and GF app versions/etc.
Related: #2604 & #3086.