`You have no permission to write to the selected folder` checkPathValidityForNewFolder failes for SMB-folders #3910

adlerweb · 2021-10-19T19:46:51Z

I am using the Windows Desktop Client to sync a folder located on a SMB share to a self hosted nextcloud instance. This worked for Versions up to 3.1.3. Starting with 3.2.0-rc1 (tested up to 3.4.4) a error ("You have no permission to write to the selected folder!") appears when adding a folder synchronization pair. My account has full write permission for the share/folder, creating files using Windows Explorer, Folder Wizard (new folder) or Settings-GUI (save debug logs) works fine. Folders located on local disks work as expected.

Ref: https://help.nextcloud.com/t/you-have-no-permission-to-write-to-the-selected-folder/125486

Expected behaviour

Add writable SMB-folder to sync pair

Actual behaviour

Error You have no permission to write to the selected folder! is displayed while writing should work fine. Next-button is disabled.

Steps to reproduce

Map a NAS drive using SMB ("Windows file share") to a local drive letter (Tested targets: Samba 4.9.x, Windows Server 2012R2, Windows 10)
Install Windows Client 3.2.0 - 3.4.4
Connect to a NC Server
When asked for a local directory browse to the mapped drive, create an empty folder using the NC GUI (aka: prove it is writable) and try to select it

Client configuration

Client version:

3.2.0-rc1 (x64)
3.3.5stable-Win64 (build 20210930); 0d9a698; Sep 30 2021, 13:30:50; Qt 5.12.10, OpenSSL 1.1.1g 21 Apr 2020
(Answers: 3.4.1-3.4.4)

Operating system:

Windows 10 Pro
Windows 11
(Forum: Windows 8.1)

OS language:

German
English

Installation path of client:
Default (C:\Program Files\Nextcloud)

Logs

Client logfile (Win10 German 3.3.5):

2021-10-19 21:34:24:941 [ info nextcloud.gui.folder.manager ]:	Folders to sync: 0
2021-10-19 21:34:24:941 [ info nextcloud.gui.folder.manager ]:	Number of folders that don't use push notifications: 0
2021-10-19 21:34:37:263 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:37:263 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:37:264 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:37:440 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d:" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:37:666 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d:/" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:38:317 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d:/o" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:38:423 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d:/ow" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:38:643 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"d:/own" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:52:133 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"D:/Owncloud-Test/test2" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:52:208 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"D:/Owncloud-Test/test2" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:52:279 [ debug nextcloud.gui.folder.manager ]	[ OCC::FolderMan::checkPathValidityForNewFolder ]:	"D:/Owncloud-Test/test2" "Sie haben keine Schreibberechtigung für den ausgewählten Ordner!"
2021-10-19 21:34:54:942 [ info nextcloud.gui.folder.manager ]:	Etag poll timer timeout
2021-10-19 21:34:54:942 [ info nextcloud.gui.folder.manager ]:	Folders to sync: 0
2021-10-19 21:34:54:942 [ info nextcloud.gui.folder.manager ]:	Number of folders that don't use push notifications: 0
2021-10-19 21:34:56:244 [ info nextcloud.gui.account.settings ]:	Folder wizard cancelled

The text was updated successfully, but these errors were encountered:

RalphGL · 2021-10-20T07:55:09Z

Same behaviour if using \\servername\share Syntax instead of a local drive letter.

Confirmed this is still an issue on 3.4.1.

SpontEIN · 2021-10-20T13:16:26Z

I am having the same issue! +1

Gizmokid2005 · 2021-11-16T02:26:58Z

+1 here as well. If I can provide anything to help reproduce, test, or provide info for this, I'm happy to. This is a fairly critical piece of my nextcloud syncing workflow.

Antivalent · 2021-11-26T18:34:53Z

+1 on Ubuntu 21.10. If there's anything I can provide to assist with fixing this, I'll gladly help.

adlerweb · 2021-11-26T19:10:48Z

+1 on Ubuntu 21.10. If there's anything I can provide to assist with fixing this, I'll gladly help.

Could you share how the path is configured? Locally mounted or using a virtual file system like GVFS?

As I guess the problem might be in Qt and not Nextcloud itself it might be worth a shot compiling against a newer or older version of Qt.

Antivalent · 2021-11-29T22:24:53Z

I just have it mounted with cifs-utils under /home/my-user/Nextcloud and it wouldn't allow me to configure that path (or any folder within) as my data folder. I was observing this issue in Windows as well, so I assumed the cause was related.

VortexOfLife · 2021-11-30T10:53:58Z

our config: Windows sync client, Network share on a Synology Nas

ornithophile · 2021-12-17T18:22:52Z

crestonbunch · 2022-01-01T16:03:11Z

I am also seeing this issue trying to sync a file mounted in WSL2. Windows can read/write just fine, but the Nextcloud client detects it as unwritable. (3.4.1)

dustbro · 2022-01-06T14:12:01Z

Same here. SMB share from TrueNAS. I'm able to read and write in Windows, but sync client says I don't have permissions.
Trying to add sync folders from NFS shares will make the sync client freeze and then crash.

erzedian · 2022-02-04T20:30:46Z

+1
Also have the same issue. Was able to work around it, by downgrading client to version 3.1.3. Then added the folder synchronisation. Then I immediatly upgraded again to version 3.4.2 and synchronization started.

I use a Synology NAS which I mount in Windows as a drive via Samba

Schneehexe · 2022-02-06T18:16:50Z

Here the same and without that SMB is involved.

This problem also exists with a normal Windows share.

Today I wanted to re-set up a machine that previously had the Nextcloud client (Windows) installed as well. The local Nextcloud directory is on a Windows share of another machine - it can be selected, but according to the message there is no write permission. Neither under the mounted drive letter nor under the server path.

But I can otherwise write from the computers as I want and have all access. Only Nextcloud is complaining.

For me, this means that I can no longer set up the synchronization and the desktop client is useless until the problem is solved.

adlerweb · 2022-02-06T18:22:19Z

Here the same and without that SMB is involved.
This problem also exists with a normal Windows share.

Windows shares are using the SMB protocol.

For me, this means that I can no longer set up the synchronization and the desktop client is useless until the problem is solved.

As pointed out you can install an older version and dismiss any popups prompting you to upgrade until the bug is fixed.

istoGer · 2022-02-07T20:37:26Z

same problem !
Trying to sync a mapped NAS-share via mapped drive-letter or UNC-path leads to
write-permission-message.

strange: sync with V:\ seemed to work -> V:\data gets the error

benems · 2022-02-19T10:28:03Z

+1

I have a dualboot system with Win10 and opensuse. The same folder sync on opensuse works, on Win10 no.

Dennis1000 · 2022-03-28T15:39:32Z

+1
Same problem: SMB-shares won't work.
Workaround: select a local directory (e.g. C:\temp\whatever), then close Nextclient, head over to %APPDATA%/Nextcloud and change that path in the nextcloud.cfg file to your SMB-network path (e.g. W:\cloud), start Nextcloud client.

fraenki · 2022-08-14T22:11:51Z

Another workaround that worked for me: setup Nextcloud client using version 3.1.3, then upgrade to the latest release.

UltimateByte · 2022-09-26T08:31:34Z

Issue confirmed

This is really a Nextcloud desktop client bug which seems confirmed by multiple sources and was introduced after 3.1.3.

Some ranting

This is a major issue and I can't believe it's still not fixed after almost a year. I wish I spoke these languages in order to submit a fix... Anyone being a C# / VBS (or whatever language this is) dev here, feel free to submit fixes. Remember that this is open source.

Use case leading to issue

Got a NAS running OpenMediaVault, with a 32TB volume, which includes an SMB share mounted as S:\ in my Windows. I've got to sync a 5TB dir to my Nextcloud instance (80TB available storage server) using a Windows desktop Nextcloud client. There is no way that I store what's on the NAS on a regular Windows desktop as I need to ensure data integrity, high availability, great read speed, and also I want HDD away from my desktop, therefore it's on a Linux NAS in RAID and connected in 10Gbit/s to my Windows while being in another room.

Context for issue

While I previously had this config working, after re-installing Windows (in order to switch from Win10 to Win11), a fresh install wouldn't be able to add it anymore as the client is claiming a permission issue. My SMB permissions seem alright to me as I'm able to create, move, modify files using the file explorer...

Known workarounds

Workaround 1: You can temporarily set a wrong dir on a local drive, close Nextcloud, edit config file (in my case in C:\Users[USERNAME]\AppData\Roaming\Nextcloud\nextcloud.cfg) and then change drive location. Might have more issues if your local drive doesn't have enough room for your data on the cloud. If so you'll need to select which dirs to sync first and It'll be alright.
Workaround 2: Setup using client 3.1.3 https://github.com/nextcloud/desktop/releases/tag/v3.1.3 I would most likely recommend this, even though I was afraid to try it as I'm now running Windows 11 and wasn't sure if compatibility was alright with an older client. But it's from Feb 18, 2021 so it should be OK.

PichlAlex · 2023-01-09T16:29:54Z

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

similar to #3201

Railsimulatornet · 2023-01-09T17:00:44Z

Thats a shame.

velocity08 · 2023-03-08T07:10:21Z

can report this is still an issue on v 3.73 windows.

sing out if i can lend a hand with anything to assist in troubleshooting.

ta

Alkl58 · 2023-03-08T21:51:47Z

After going down the rabbit hole of C++ and Qt I have come to the following conclusion:

NTFS Permissions checks are activated (with this Qt/C++ actually checks permissions on NTFS systems)

desktop/src/gui/folderman.cpp

Line 1652 in 30cfba4

Utility::NtfsPermissionLookupRAII ntfs_perm;
Write Permissions are tested

desktop/src/gui/folderman.cpp

Line 1667 in 30cfba4

if (!selFile.isWritable()) {

Now here is the problem (I think - on my end with an SMB share from OpenMediaVault):
The isWritable() function checks only(?) for write permissions for the user, owner, group or anyone.

However, its technically correct - when opening the folder permissions in Explorer, it shows that I don't have those permissions. The actual permission for me being able to read/write/delete is not covered by the "base" permissions of explorer, it's covered by the "special permissions".

It looks similar to this (just imageine it being an SMB share lol):

My best guess is, that Qt's implementation doesn't check for write permissions covered by the "special permissions" of Windows Explorer.

As it's my first time with C++, I have looked into if we could use GetFileSecurityA from the Win32 API, however I am not sure if it would even work for SMB shares (read something about limitations etc).

Now to my really bad workaround (KISS):

#ifdef Q_OS_WIN
#include <cerrno>
#endif

if (!selFile.isWritable()) {
    #ifdef Q_OS_WIN
    // Really bad test
    auto testpath = path.toStdString() + "\\results.txt";
    FILE *fp = fopen(testpath.c_str(), "w");
    if (fp == NULL) {
        if (errno == EACCES) {
            return FolderMan::tr("You have no permission to write to the selected folder!");
        }
    }
    #else
    return FolderMan::tr("You have no permission to write to the selected folder!");
    #endif
}

This solution is ~~most likely~~ the most idiotic way (it creates an actual file).

Realistically I only see the following solutions:

Implement a scary Windows API to check special folder permissions (which might not even work)
Somehow detect if the Folder is on a SMB share and then probe if it can actually write something (similar to my stupid solution)
Give the user an option in the settings to skip Utility::NtfsPermissionLookupRAII ntfs_perm; on Windows (with a proper explanation why this setting exist)
...

JohanBraeken · 2023-03-09T06:33:54Z

Thank you for this analysis, @Alkl58!

This is absolutely not an idiotic way of testing!
From an information security perspective this is actually a very good way: You just do what you need to do and if it fails, you handle the error. (As part of the error handling you can do some tests to find out exactly what went wrong.)

If you perform any test upfront that differs from the actual use case, you can run into all kinds of (security) problems. Very often it is because the test is not representative (as this issue demonstrates), or you end up with bugs that fall under the TOC/TOU class of software bugs. (https://en.wikipedia.org/wiki/Time-of-check_to_time-of-use)

cmdrwgls · 2023-03-09T06:38:56Z

Could we please just get a button that says "yes I know you found a problem, now do it anyway"? Not to suggest solving the problem is a bad thing, just that fixing the workflow so that I don't have to create a folder, point nextcloud to it, finish setup, quit nextcloud, edit a config file, restart nextcloud, delete the folder I created ... requires nothing more than an ignore button.

…

On 2023-03-08 16:51, Alkl58 wrote: After going down the rabbit hole of C++ and Qt I have come to the following conclusion: 1. NTFS Permissions checks are activated (with this Qt/C++ actually checks permissions on NTFS systems) https://github.com/nextcloud/desktop/blob/30cfba49cacad8237f5d23606117c22a793af63f/src/gui/folderman.cpp#L1652 2. Write Permissions are tested https://github.com/nextcloud/desktop/blob/30cfba49cacad8237f5d23606117c22a793af63f/src/gui/folderman.cpp#L1667 ------------------------------------------------------------------------ Now here is the problem (I think - on my end with an SMB share from OpenMediaVault): The isWritable() <https://doc.qt.io/qt-6/qfileinfo.html#isWritable> function checks only(?) for write permissions <https://doc.qt.io/qt-6/qfiledevice.html#Permission-enum> for the user, owner, group or anyone. *However, its technically correct* - when opening the folder permissions in Explorer, it shows that I don't have those permissions. The actual permission for me being able to read/write/delete is not covered by the "base" permissions of explorer, it's covered by the "special permissions". It looks similar to this (just imageine it being an SMB share lol): <https://camo.githubusercontent.com/a8ed1b2bbc38198f305e58f9e532c955cd00ef249f504704640798c98872836d/68747470733a2f2f692e737461636b2e696d6775722e636f6d2f64753844352e706e67> My best guess is, that Qt's implementation doesn't check for write permissions covered by the "special permissions" of Windows Explorer. As it's my first time with C++, I have looked into if we could use GetFileSecurityA <https://learn.microsoft.com/de-de/windows/win32/api/winbase/nf-winbase-getfilesecuritya?redirectedfrom=MSDN> from the Win32 API, however I am not sure if it would even work for SMB shares (read something about limitations etc). Now to my really bad workaround (KISS): #ifdef Q_OS_WIN #include <cerrno> #endif if (!selFile.isWritable()) { #ifdef Q_OS_WIN // Really bad test auto testpath = path.toStdString() +"\\results.txt"; FILE *fp =fopen(testpath.c_str(),"w"); if (fp ==NULL) { if (errno == EACCES) { return FolderMan::tr("You have no permission to write to the selected folder!"); } } #else return FolderMan::tr("You have no permission to write to the selected folder!"); #endif } This solution is most likely the most idiotic way (it creates an actual file). Realistically I only see the following solutions: 1. Implement a scary Windows API to check special folder permissions (which might not even work) 2. Somehow detect if the Folder is on a SMB share and then probe if it can actually write something (similar to my stupid solution) 3. Give the user an option in the settings to skip |Utility::NtfsPermissionLookupRAII ntfs_perm;| on Windows (with a proper explanation why this setting exist) 4. ... — Reply to this email directly, view it on GitHub <#3910 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADRQMVZLFLCOYVASXCBXGCTW3D5P7ANCNFSM5GJ6G6JQ>. You are receiving this because you commented.Message ID: ***@***.***>

Leah96xxx · 2024-06-02T17:47:15Z

This doesn't just seem to be for SMB folders. It did this to me pointing to my own Documents folder in C:\Users\username

It worked fine yesterday, but I had to remove and re-add the sync pair after changing how my server's storage was mounted, at which point it wouldn't let me reselect it after removing the old pair. Other previously paired folders seem to be fine, just this one.

Edit: Issue persists after clean reinstall of the Nextcloud client. Pretty much renders Nextcloud useless for me now since syncing my Documents folder was one of my primary uses

Edit 2: It looks like something added explicit Users deny write permission to my Documents folder. Even I was almost locked out from editing its contents. Can't think of anything that could have caused that. I found this by manually adding the sync pair to the config file, then finding that Nextcloud couldn't create a database file in Documents. Upon checking, I noticed that I couldn't even create a folder as admin. Thankfully I was able to remove that permission and fix the issue. Just need to try and find what applied that permission change in the first place.

schwabeltier · 2024-11-22T09:40:32Z

I have a similar problem. I use a cloud hoster and foldersync between cloud and windows 10. I changed nothing and it appears that my Windows machine && my Sync does not work properly any more.
Windows states, that I have no possibilty to write in the first folder level (below I can write!), because there is a waiting sync by Nextcloud-Client.
And too my nextcloudclient won`t sync any folder level.
I changed nothing, I have normal permissions for all folders. I tried it and nothing helped.
Nextcloud states: You have no write permissions for the selected folder!

adlerweb added the bug label Oct 19, 2021

FlexW added confirmed bug approved by the team feature: 🔄 sync engine os: 🚪 Windows labels Oct 20, 2021

This comment was marked as duplicate.

Sign in to view

This comment was marked as spam.

Sign in to view

Alkl58 mentioned this issue Mar 9, 2023

Windows: Additional write permissions check #5510

Closed

joshtrichards added feature: ⚙️ settings and removed feature: 🔄 sync engine labels Aug 20, 2024

joshtrichards changed the title ~~Windows >= 3.2.x: checkPathValidityForNewFolder failes for SMB-folders~~ You have no permission to write to the selected folder checkPathValidityForNewFolder failes for SMB-folders Aug 20, 2024

joshtrichards mentioned this issue Aug 20, 2024

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

Closed

Rello added feature: ☁️ GUI System tray icon and menu. and removed feature: ⚙️ settings labels Dec 9, 2024

You have no permission to write to the selected folder checkPathValidityForNewFolder failes for SMB-folders #3910

You have no permission to write to the selected folder checkPathValidityForNewFolder failes for SMB-folders #3910

Comments

adlerweb commented Oct 19, 2021 • edited Loading

Expected behaviour

Actual behaviour

Steps to reproduce

Client configuration

Logs

RalphGL commented Oct 20, 2021 • edited Loading

SpontEIN commented Oct 20, 2021

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as duplicate.

Gizmokid2005 commented Nov 16, 2021

This comment was marked as duplicate.

This comment was marked as duplicate.

Antivalent commented Nov 26, 2021

adlerweb commented Nov 26, 2021

Antivalent commented Nov 29, 2021

VortexOfLife commented Nov 30, 2021

This comment was marked as duplicate.

ornithophile commented Dec 17, 2021

This comment was marked as duplicate.

This comment was marked as duplicate.

crestonbunch commented Jan 1, 2022

dustbro commented Jan 6, 2022 • edited Loading

erzedian commented Feb 4, 2022

Schneehexe commented Feb 6, 2022

adlerweb commented Feb 6, 2022

istoGer commented Feb 7, 2022

benems commented Feb 19, 2022

This comment was marked as duplicate.

This comment was marked as duplicate.

Dennis1000 commented Mar 28, 2022 • edited Loading

This comment was marked as duplicate.

fraenki commented Aug 14, 2022

UltimateByte commented Sep 26, 2022

Issue confirmed

Some ranting

Use case leading to issue

Context for issue

Known workarounds

This comment was marked as duplicate.

This comment was marked as duplicate.

This comment was marked as spam.

PichlAlex commented Jan 9, 2023 • edited Loading

Railsimulatornet commented Jan 9, 2023

velocity08 commented Mar 8, 2023

Alkl58 commented Mar 8, 2023

JohanBraeken commented Mar 9, 2023 • edited Loading

cmdrwgls commented Mar 9, 2023 via email

Leah96xxx commented Jun 2, 2024 • edited Loading

schwabeltier commented Nov 22, 2024 • edited Loading

`You have no permission to write to the selected folder` checkPathValidityForNewFolder failes for SMB-folders #3910

`You have no permission to write to the selected folder` checkPathValidityForNewFolder failes for SMB-folders #3910

adlerweb commented Oct 19, 2021 •

edited

Loading

RalphGL commented Oct 20, 2021 •

edited

Loading

dustbro commented Jan 6, 2022 •

edited

Loading

Dennis1000 commented Mar 28, 2022 •

edited

Loading

PichlAlex commented Jan 9, 2023 •

edited

Loading

JohanBraeken commented Mar 9, 2023 •

edited

Loading

Leah96xxx commented Jun 2, 2024 •

edited

Loading

schwabeltier commented Nov 22, 2024 •

edited

Loading