Cannot add NetworkDrive as sync location anymore (You have no permission to write to the selected folder)

[Xansala]

Expected behaviour

Newly installed Nextcloud instance where I want to folder sync connection on my Network Drive. Add a folder location and then select the folder on the server. It worked at least till 3.1.0 to do that.

Actual behaviour

Adding a network drive gives the following error message and the adding cannot be completed:

Needless to say that I have of course access to the folder and can add/delete/amend files in it.

Steps to reproduce

1. Create a network location (does not matter if mapped to a drive or added with \...)
2. Add that location to the folder sync connection

Client configuration

Client version: 3.2.0

Operating system: Win 10 x64 20H2

OS language: English

Installation path of client: C:\Program Files\Nextcloud

Server configuration

Nextcloud version: 21.0.1

[cm-schl]

Hi,

my colleague made some tests because we're facing the same problem: if you temporarily on this folder give full permissions to "Everyone" the wizard seems to accept the path. Afterwards you can also remove the full permission and the sync works nevertheless.

Can't say whats the cause of this behavior, but seems to be a bug of the Wizard checking some rights...

[Xansala]

@cm-schl: Cool, that worked for me too! So really looks like an issue in the rights checking.

[buzter]

Short update: Facing the same problem with 3.3.0 since last friday. Reinstalling the previous and - until updating to 3.3.0 working - version 3.2.4 unfortunately doesn't help.

[FlexW]

@Jeepsterdave68 this task is not scheduled yet. Feel free to work on it yourself :)

[cm-schl]

I've looked at

desktop/src/gui/folderman.cpp

Line 1557 in ed9671c

if (!selFile.isWritable()) {

and ask myself if this is somehow connected with the NTFS Permissions (https://doc.qt.io/qt-5/qfileinfo.html#isWritable)?

I'm using Samba and the PC trying to access the share is using Windows 10 - maybe there is some misunderstanding when Nextcloud Desktop Client tries to retrieve the NTFS Permissions on linux shares? Also @Aldaris1985 seems to use a Linux NAS.

[Xansala]

I'm using Samba and the PC trying to access the share is using Windows 10 - maybe there is some misunderstanding when Nextcloud Desktop Client tries to retrieve the NTFS Permissions on linux shares? Also @Aldaris1985 seems to use a Linux NAS.

Confirmed, I am using a Linux NAS (Synology DS218+).

[crackerjam]

Can also confirm this happens on version 3.4.2, and also happens with mapped Windows shares. However, I am connecting to a share that is on a domain, while my workstation is not on that domain, so the share is mapped with saved credentials. Perhaps there's an issue with this check properly accessing those credentials?

[cm-schl]

So you're saying that the share is hosted on a Windows Server and not a Samba share?
Info: we're not using saved credentials to access the shares - these are on the same domain in our case...

[crackerjam]

So you're saying that the share is hosted on a Windows Server and not a Samba share?

That's correct. The share is on Windows Server 2016 running on a domain, where my workstation is just in its own workgroup, not part of any domain. The share is also mapped to a drive letter though, which includes setting credentials. It seems unusual that Windows wouldn't just make that work as if it was local transparently.

[PichlAlex]

i can confirm this issue when using completly updated Windows 10 or 11 and a SMB Share on a
TrueNAS Core 13.0-U3.1 and Nextcloud Desktop Client 3.6.4

[eusi]

I used Nextcloud on a path like \nas\Data\Business\Nextcloud for years. Today I made the "mistake" to remove the sync because I wanted to change the path to \nas\Data\Business\Data\Nextcloud (one folder deeper).
Since I cannot link/sync to this folder (nor to the old one), because of this (GUI?) bug, I cannot use Nextcloud any longer -.-
Desktop. Win10, Nextcloud 3.4.1.

Workaround
To make it work again I installed the older Nextcloud 3.1.3. Setup the new network path (which still works with that version!) and then update to the latest Nextcloud version (for me 3.7.3). And voila Nextcloud works again with such a path.

[simonai1254]

Just to add: This bug is still present in version 3.10.1 on Windows 10 with a Synology DS214+ share which is very annoying.

Edit: I noticed the pull request #5510 is in the final stretch, so hopefully it will make it into the next release :)

[republicandaddy]

This is an old post, but while running the Windows client 3.13.0, I ran into this same error. I thought I’d share the fix I found in case anyone else comes across this post with this issue.

My setup is simplified. This is a local folder on a non-root local drive, but trying to sync it to my Nextcloud server. I kept getting this same error AFTER the initial sync worked.

I hadn’t changed a thing, except a recent upgrade to the client.

So, after some testing and comparing the permissions with the user’s folder on this drive with those of another folder that did NOT get this same message, it turned out that the upgrade appeared to have randomly inserted a new permissions limitation in the security tab. It literally set DENY to all local users. As soon as I removed this new entry, everything worked swimmingly.

Hope this helps someone else in the future.

Cheers!

[simonai1254]

This issue might have been resolved with version 3.11, at least merge request #6209 (successor to #5510) was included in that version...

I have not yet tried again to reconnect a network drive.

[silvansievers]

This is an old post, but while running the Windows client 3.13.0, I ran into this same error. I thought I’d share the fix I found in case anyone else comes across this post with this issue.

My setup is simplified. This is a local folder on a non-root local drive, but trying to sync it to my Nextcloud server. I kept getting this same error AFTER the initial sync worked.

I hadn’t changed a thing, except a recent upgrade to the client.

So, after some testing and comparing the permissions with the user’s folder on this drive with those of another folder that did NOT get this same message, it turned out that the upgrade appeared to have randomly inserted a new permissions limitation in the security tab. It literally set DENY to all local users. As soon as I removed this new entry, everything worked swimmingly.

Hope this helps someone else in the future.

Cheers!

Thank you a lot for that hint! I had the same issue after upgrading to Windows client 3.13.2. Removing the entry "\Users", which had all write and read permissions but also a greyed out "deny everything" option ticked, it works again.

[joshtrichards]

Duplicate of #3910

(this one actually came first but more people are following the other one so let's consolidate there).