Migrating Existing (Good) NextCloud to new Web Server has triggered Brute-Force Protections against Floccus

[sproggit]

Which version of floccus are you using?

V5.9.1

How many bookmarks do you have, roughly?

4,419

Are you using other means to sync bookmarks in parallel to floccus?

No

Sync method

Nextcloud Bookmarks

Which browser are you using? In case you are using the phone App, specify the Android or iOS version and device please.

Firefox 150.0.0

Which version of Nextcloud Bookmarks are you using? (if relevant)

v16.1.4

Which version of Nextcloud? (if relevant)

Hub 26 Winter (33.0.2)

What kind of WebDAV server are you using? (if relevant)

NextCloud Defaults

Describe the Bug

Attempts by Floccus to synchronise with the NextCloud Bookmark app result in my client IP being "brute-force blocked" by the integrated/internal NextCloud controls.

This is a particularly unusual scenario...

I have just migrated my NextCloud instance between two Raspberry Pi computers.
Both Pi's were running Raspbian "Trixie" as their OS.

To minimise risks of dependency issues, I first confirmed that I was running the latest edition of NextCloud, then used the Web Installer script to perform a fresh install of Nextcloud on my destination host [different URL, obviously], then installed the same set of Apps and eliminated the handful of "Security & Setup warnings" issued by NextCloud.

When I had a good, clean installation, I followed NextCloud's own "how to move" instructions - which basically consists of creating a compressed tar file of the entire contents of the NextCloud webroot, moving it to the destination server and unpacking, then porting across the Apache2 site file and porting the IP address [I'm using Virtual IP-based virtual hosts in this setup].

NextCloud started first attempt and has run clean with no issues being reported, except for the fact that Floccus is now triggering the NextCloud Brute Force protections, which in my case it has never done before.

The only other oddity is that when I first connected my browser to the ported instance of Floccus, the sync entries in Floccus all immediately failed. [I have 3 - "Bookmarks Toolbar", "Bookmarks Menu" and "Other Bookmarks", as these are the 3 "TLDs" of my bookmark library... ]

However, I simply opened Floccus and selected the "Options" for each instance, re-typed my password and hit "Start".

I now have a work-around in place - I have used the Administration>>Security tab in the NextCloud Admin panels to add the IP address of my workstation to the "Brute-force allow list"... and this has definitely suspended the repeat of the issue. However, this is only a temporary fix, since I'm going to want to access this NextCoud instance when I'm travelling - and in that use case my IP address will be changing regularly.

The "odd thing" here is that to the best of my knowledge/ability, I have performed a like-for-like port of this NextCloud instance between two servers both running the same release of OS. I used "dpkg --list" on both Pi machines and piped the output to text files to compare and confirm packages aligned. I used "sudo apachectl -M" and compared the active Apache modules. I have made minimal edits to e.g. my local php.ini files - all guided by NextCloud's Admin/Setup warning messages.

I have ported NextCloud between servers before - several times - without issue. This is the first time I've hit this specific challenge and I'm 99% sure it's something I've done/failed to do, but I'm struggling to triage...

IMPORTANT NOTE
One of the few things I "got wrong" in my initial configuration was that I failed to "a2enmod" the "Rewrite" module. This appears to be needed by each of the WebDAV/CalDAV/CardDAV components of NextCloud, because that triggered a weird error that reported an issue for CalDAV but only CalDAV - but which on testing showed that all 3 DAV implementations were broken. I worked backwards, realised the module was not enabled and enabled it. This resolved the NextCloud Error message, but by that time of course Floccus had attempted and failed to Synchronise.

Is it possible that the initial absence of the Apache2 rewrite module has put the "Bookmark" app in to a fragile state that is causing this issue?

Expected Behavior

I would expect Floccus to interact with NextCloud's API in a way that does not trigger the brute-force protections on the server.

The implication here is that the activity that is repeating "again and again" is part of the authentication process, using the credentials stored in the Floccus instance on my browser [neither of which have changed within this migration]. As noted, when Floccus first failed to connect after starting the ported instance of NextCloud for the first time, I did re-submit my credentials for each of the 3 configured replication entries. That seems to work - I can click the "run now" button and each will run through to conclusion without issue... but the next time I start my browser, not only does it fail, it brute-force locks my NextCloud ID [requiring me to use the occ command to unlock my client IP address].

To Reproduce

Issue appears with 100% frequency each time I re-launch my Firefox browser... at least it did - right up to the point where I allow-listed my client's IP address in NextCloud's configuration settings.

floccus-5.9.1-2026-04-25-full_obfuscated.log

Debug log provided

• I have provided a debug log file

[github-actions]

Hello! 👋

Thank you for taking the time to open this issue with floccus. I know it's frustrating when software causes problems. You have made the right choice to come here and open an issue to make sure your problem gets looked at and if possible solved. Let me give you a short introduction on what to expect from this issue tracker to avoid misunderstandings. I'm Marcel. I created floccus a few years ago, and have been maintaining it since. I currently work for Nextcloud which leaves me with less time for side projects like this one than I used to have. I still try to answer all issues and if possible fix all bugs here, but it sometimes takes a while until I get to it. Until then, please be patient. It helps when you stick around to answer follow up questions I may have, as very few bugs can be fixed directly from the first bug report, without any interaction. If information is missing in your bug report and the issue cannot be solved without it, I will have to close the issue after a while. Note also that GitHub in general is a place where people meet to make software better together. Nobody here is under any obligation to help you, solve your problems or deliver on any expectations or demands you may have, but if enough people come together we can collaborate to make this software better. For everyone. Thus, if you can, you could also have a look at other issues to see whether you can help other people with your knowledge and experience. If you have coding experience it would also be awesome if you could step up to dive into the code and try to fix the odd bug yourself. Everyone will be thankful for extra helping hands! If you cannot lend a helping hand, to continue the development and maintenance of this project in a sustainable way, I ask that you donate to the project when opening an issue (or at least once your issue is solved), if you're not a donor already. You can find donation options at https://floccus.org/donate/. Thank you!

One last word: If you feel, at any point, like you need to vent, this is not the place for it; you can go to the Nextcloud forum, to twitter or somewhere else. But this is a technical issue tracker, so please make sure to focus on the tech and keep your opinions to yourself.

Thank you for reading through this primer. I look forward to working with you on this issue! Cheers! 💙

[marcelklehr]

Hey @sproggit
Thank you for taking the time to give feedback! Brute force protection is distinct from rate limiting in that BFP only kicks in if the requests triggered an error, while rate limiting kicks in even for good requests, if there are more than the configured limit. The public bookmarks API only configures a brute force protection, which might be kicking in here for some reason.

Could you check the network requests with the following steps?

Firefox

• Go to about:debugging
• go to "This firefox"
• click on Inspect button next to floccus entry
• go to the network tab in the inspector
• trigger a sync by clicking on sync now for the account of your choice.
• check the failing network requests

Chrome

• Go to chrome://extensions
• enable Developer mode
• click on dist/html/background.html button in floccus' entry next to "Inspect views: "
• go to the network tab in the inspector window
• trigger a sync by clicking on sync now for the account of your choice
• check the failing network requests

[sproggit]

Marcel,
Thanks so much for responding. I'm going to repeat, just for clarity: "I suspect this is something I did wrong", because, as I say, I've ported NextCloud before and installed/upgrade/migrated browsers loads of times without issues.
I did exactly as you suggested above and I embed the results as a screen scrape of the window once the sync runs to completion [I chose my Toolbar profile as that has the smallest number of bookmarks in it, but can test with others if required].

You'll see that the results are a complete success - but I suspect this is because I have allow-listed my workstation in NextCloud's "Security" section. Happy to provide more data/details if needed.

Thank you!

[marcelklehr]

Ah, yes, I would need to see the results for after you removed your IP from the allow list

[sproggit]

Hi Marcel, I think this is a case of "Curiouser and Curiouser," said Alice...
I removed my workstation IP from the NextCloud "AllowList" value and re-ran a bookmark sync. My first choice was my "BookMarks Toolbar" data set, since it is the smallest... but that worked without error. When it finished a did a page refresh in the NC Admin panels to see if it had tripped the throttling response, but it had not. I took the screen shot attached here.

I then moved on to my "Bookmarks Menu" data set, which is by far the largest, covering maybe 3,800 of the 4,400 or so bookmarks I have. This, too, moved all the way to completion. I re-checked the state of my IP Address in the NC Admin Panels and I was still not blocked or throttle, but I noticed that the Menu sync took much, much less time than it had when I saw the issues.

In my original post for this possible bug report, I noted that after I had moved the "back end" of my NextCloud instance, all Floccus replication failed with errors until I had edited each of my 3 configured replication settings by re-entering my User Password and re-authorising Floccus to connect to NC at the back end. The first replication took much, much longer. I am starting to wonder if there was something special about that first replica after moving the NC web site that maybe resulted in it being treated as a "first time replication", except maybe without some of the safeguards that I would get if I had set the appropriate options in Floccus [I did not do that here].
Anyway, my attempt to syn my "Bookmarks Menu" data set produced so much on-screen output that it quickly scrolled off the top of the window... I don't think pasting that here helps, so I exported the log file and attached that instead.

Happy to experiment further or provide anything else you need... but just to confirm, today a sync worked, without the workstation listed in the "AllowList" and without the workstation being throttled at the end of the sync process. [ That result seems to me to be == "All OK Now"... but I still can't explain why i saw the errors over the weekend, unless it is related to the theory I express here...

Hmm... I've been trying to add the "devtools_Archive*.har" file, but GitHub won't accept it. I've tries compressing it to a Zip file, since the GitHub documentation said that would be acceptable, but that is also being rejected. If you can suggest how to get this file uploaded, I'm happy to try again.

[marcelklehr]

Heh, interesting! I suspect that the auth token that floccus had stored was not valid for the new nextcloud instance and thus you ran into authentication errors and were brute force throttled. Today you have re-connected the profiles and the auth tokens are valid and nextcloud has forgotten about the brute force attempts, so all is good :)

[sproggit]

> Heh, interesting! I suspect that the auth token that floccus had stored was not valid for the new nextcloud instance and thus you ran into authentication errors and were brute force throttled. Today you have re-connected the profiles and the auth tokens are valid and nextcloud has forgotten about the brute force attempts, so all is good :)

Well, that's the interesting thing...

In order to move NextCloud to a new server, this is what I did:-

1. Build the new machine and OS, install Apache, PHP, etc. Use e.g. "sudo apachectl -M" to make sure that I had the correct selection of Apache and PHP modules installed.
2. Perform a "Test Installation" of NextCloud [using a different URL] and then add in all the "Apps" that I have in my main/production setup, so as to ensure that functionality was supported. [ For example, I learned that I have to have the "Redis" server installed and running for some of my NextCloud apps - and unless I tried to install and use those NC apps, I would see NextCloud running, think it was OK, and hit issues...
3. On the original NC host, put NextCloud in to Maintenance Mode using the OCC command.
4. Create a tar file of the entire NextCloud environment and then copy that tar file to the destination server. Also copy across the "/etc/apache2/sites-available/" configuration file and the public certificate and private key for my main NextCloud instance.
5. Un-tar the NextCloud site file in to /var/www/ - preserving user and group ownership values - and then double-check file and folder permissions.
6. Start the Apache2 instance and access the URL. Confirm that I see the message warning me that the site is in maintenance mode.
7. Use the OCC command to take NextCloud out of Maintenance Mode
8. Go back to the home page and successfully log in...

Because I was not moving the database server or making any changes on the "back end" of that nature, I did not have to manually edit NextCloud's configuration file with new database server details.
When I came out of maintenance mode, everything worked... I kept a close watch on the NextCloud logs and apart from the error previously acknowledged, had no issues.

I am very happy that everything seems to have resolved itself... but I still wonder what I did or did not do that triggered this unexpected behavior. It is perhaps the technologist in me - I refuse to believe I have truly "fixed" something until I understand how it went wrong in the first place and can see and understand how my actions in response were able to resolve the issue. Anything less than that and I tend to think "the fault might come back"...

Thanks again for your patience.

[marcelklehr]

Anything less than that and I tend to think "the fault might come back"...

If it comes back, we can always reopen this here and examine the situation then :)