Some or all of the below information will be requested if it isn’t supplied; for fastest response please provide as much as you can.
The Basics
Nextcloud Server version (e.g., 29.x.x):
30.0.5 in docker container
Operating system and version (e.g., Ubuntu 24.04):
Windows 11 dual boot with:
Linux Mint
Web server and version (e.g, Apache 2.4.25):
No additional server beyond nextcloud container
Reverse proxy and version _(e.g. nginx 1.27.2)
N/A
PHP version (e.g, 8.3):
?
Is this the first time you’ve seen this error? (Yes / No):
new install
When did this problem seem to first start?
new install
Installation method (e.g. AlO, NCP, Bare Metal/Archive, etc.)
AIO via docker
Are you using CloudfIare, mod_security, or similar? (Yes / No)
No
Summary of the issue you are facing:
I run a dual boot laptop sharing a data drive. The folder in question is accessible in either OS. What I’m trying to accomplish is to have nextcloud sync the folder no matter which OS is running
Steps to replicate it (hint: details matter!):
Installed client in Linux
Sync’d folder successfully
Switched to Windows and installed client
Attempted to choose the same folder from the drive to sync
Error message: “Warning: The folder D:\Nextcloud is used in a folder sync connection”, also dimmed “Next” button so there is no possibility of ignoring the error
It looks as though others have encountered this in the past, but I’ve tried various suggested solutions (rebooting, changing “folder ignore” options, etc) and had no luck.
I didn’t go digging for log entries, but I suspect there are none as it won’t even let me TRY. I made a backup of the folder, so I’m tempted to try random things like deleting the hidden files, but I’d prefer not to completely break it.
Apologies for the relatively low info post - I’m out of my depth with this stuff. Also, lower on patience than I would normally be - it took a lot of effort for me to figure out setting the container up in the first place. Fairly basic networking task, I’m sure, but very far from my area of expertise.
No one? Honestly, I can live with it as-is: I mostly use the sync function to very conveniently upload photos presorted into separate folders as I take them and I generally interact with them in Windows. If I REALLY need something in linux, I can always just switch to Windows, sync and come back. I mostly just wanted to know if this is disabled on purpose for some reason, or if I’m just doing something wrong.
Personally, I just use drives that are very large or sync only what I need on each OS. It is redundant, but I don’t have to try to circumvent protections and I don’t have to resolve conflicts as much. I have a desktop that syncs everything and the server that syncs everything, and a laptop the bare essentials for work. That way I have redundancy in the backups and what I need for work.
If you want, you could let it sync to a new folder from scratch, but stop it by turning off NextCloud. Then you modify the config file to have it sync to a different directory. This allows you to bypass the window that is not letting you move forward. There are variables in the Linux config whose defaults I did not like. There’s one for timing.
At first you might encounter collisions for every file. Choose to keep the ones on the “server”. After the database is seeded, I think it might work. Might. It is definitely not recommended. A better way might be to use a VM on Windows (in the background) that has the single purpose of running NextCloud. You attach your Linux volume into it and make it use your actual files. If the VM’s version matches the NextCloud version in your Linux OS, it might just work. Not recommended, but it could be fun. Only attempt this if you already know how to attach volumes to a VM and you know where to modify config files in Linux and you know to make symbolic and hard links in Linux.
Here’s what an AI bot says about config file locations.
Your user-specific Nextcloud configurations are typically stored in:
User Data & App Configs:
~/Nextcloud/ (if using the Nextcloud client, this is the default sync folder)
~/.config/Nextcloud/ (GUI client settings)
~/.cache/Nextcloud/ (cached metadata)
~/.local/share/Nextcloud/ (additional data, like logs)
Thanks for the detailed and thoughtful response. I think having to get that fiddly for a work around, pretty clearly indicates that the developers didn’t intend for it to work. I can understand why - it does seem like there’s a lot of potential for buggy behavior there, sharing they physical drive while using two different OSes to sync it. I mostly wanted to be sure there wasn’t just some setting that I had wrong.
I played around with it and it currently syncs on the windows side, which is how the Google Drive account it’s replacing was working for years, so obviously I can live with it. I tend to work on the windows side (not by choice) and play on the Linux side. My main need for synced drives is work related, and it would be more hassle to deal with lost or corrupted files than it would be for me to occasionally have to boot into windows to sync a file for linux.
I think we can consider this - if not entirely solved, at least working as intended. Thanks for the help.
If you want syncing to occur even when on the Linux side and safely, the safest way is for data to be duplicated.
If you want windows to receive the changes at the end of the day so it syncs changes when it turns on, then just mounting the files into Linux and using them works. You will not get new files provided by other users while you work, though.
If you have another machine that can always be on that accepts SSH (cheap old desktop with plenty of storage) , then a couple rsyncs can probably work. Here’s what you could do:
Big machine is called B, work Linux is L, work Windows is W.
Set B to sync all from the server. Wait for completion.
Set up SSH on the machine to accept local connections
Sync left: On L, each day you work, start with syncing from B to L. Consider using the --delete flag if you know that yesterday you “sync right”
Sync right: At end of work day, rsync the folders to B. Consider using the --delete flag if you know the that you detected files and you want that reflected on the server.
Note that this is NOT safe if a coworker is editing the same folders throughout the day. rsync with --delete is very destructive and missing a “/” with rsync can have very heavy repercussions.
If you are like me, you might be using Linux by choice and are trying to be compatible. I applaud you. Sometimes the easiest way to do that is to manage 2 machines or to have a rig that is big enough to run Linux in a VM. Windows has the Linux subsystem now and it has been getting better. It is “like” running Linux in a VM. In fact, I think it is running in a hypervisor. Feel free to reason me or DM with details if you want to explore these ideas together or grant further insight into the set up.
I do appreciate the continued brainstorming. Someone may search this at some point and find just the right solution. For my part this is sort of a “juice isn’t worth the squeeze” situation. My crusty old laptop struggles enough to run windows without any VMs (though it runs just fine with Linux… ) and duplicating the drive on the machine is out for similar reasons.
No coworkers on this as the nextcloud instance is running off my own server at home, entirely for my convenience. Most our our field guys are either emailing themselves photos, plugging their phones in to their laptops, or some other variation. I used to use Google drive to sync the photos from my phone, but I’ve been trying to de-Google as much as possible.
I have to work with the photos in Word for the convenience of people downstream in the process. We have a very specific template we use - there’s an application that lifts the text and images to move into another proprietary program that we use to process our reports… Not my part in it, but I tried LibreOffice previously and got an email that the file was “all messed up”. Less work for me to deal with Windows than to troubleshoot the problem. I suppose I could try running Word in Wine…
The proprietary software at the core of the whole process is completely antiquated, but that end of it is way out of my hands. Our customers value consistency in the reports we deliver and no one has decided to step up and figure out a better way to deliver something formatted the same but running on current software.