RalphGL
commented
2 years ago Same behaviour if using \\servername\share Syntax instead of a local drive letter.
- Confirmed this is still an issue on 3.4.1.
Open adlerweb opened 2 years ago
RalphGL
commented
2 years ago Same behaviour if using \\servername\share Syntax instead of a local drive letter.
SpontEIN
commented
2 years ago I am having the same issue! +1
maticjersic
commented
2 years ago +1
RafaelSz
commented
2 years ago +1
fo5Vi7t7yw2L
commented
2 years ago +1
Gizmokid2005
commented
2 years ago +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.
VortexOfLife
commented
2 years ago +1
kxdyz
commented
2 years ago +1
Antivalent
commented
2 years ago +1 on Ubuntu 21.10. If there's anything I can provide to assist with fixing this, I'll gladly help.
adlerweb
commented
2 years ago +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
commented
2 years ago 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
commented
2 years ago our config: Windows sync client, Network share on a Synology Nas
ornithophile
commented
2 years ago +1
ornithophile
commented
2 years ago 
JohanBraeken
commented
2 years ago +1
ornithophile
commented
2 years ago Confirmed still an issue on 3.4.1.
crestonbunch
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago +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
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago +1
I have a dualboot system with Win10 and opensuse. The same folder sync on opensuse works, on Win10 no.
Railsimulatornet
commented
2 years ago same Problem with client 3.4.3
cmdrwgls
commented
2 years ago +1 Problem still present in 3.4.4
Please don't leave client-breaking bugs open for years. Please. Syncing to a network share CAN'T be an edge case.
Dennis1000
commented
2 years ago +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.
LarsK1
commented
2 years ago +1
fraenki
commented
2 years ago Another workaround that worked for me: setup Nextcloud client using version 3.1.3, then upgrade to the latest release.
UltimateByte
commented
1 year ago This is really a Nextcloud desktop client bug which seems confirmed by multiple sources and was introduced after 3.1.3.
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.
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.
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...
Schroedinger00
commented
1 year ago +1
chrystt
commented
1 year ago +1
cmdrwgls
commented
1 year ago STILL PRESENT as of v3.6.2.
PichlAlex
commented
1 year ago 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
Railsimulatornet
commented
1 year ago Thats a shame.
velocity08
commented
1 year ago 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
commented
1 year ago After going down the rabbit hole of C++ and Qt I have come to the following conclusion:
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:
Utility::NtfsPermissionLookupRAII ntfs_perm; on Windows (with a proper explanation why this setting exist)JohanBraeken
commented
1 year ago 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
commented
1 year ago 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:
- 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
- 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
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)
- ...
— Reply to this email directly, view it on GitHub https://github.com/nextcloud/desktop/issues/3910#issuecomment-1460924930, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADRQMVZLFLCOYVASXCBXGCTW3D5P7ANCNFSM5GJ6G6JQ. You are receiving this because you commented.Message ID: @.***>
Leah96xxx
commented
3 months ago 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.
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
Client configuration
Client version:
Operating system:
OS language:
Installation path of client: Default (C:\Program Files\Nextcloud)
Logs