This warning message is worth a dedicated thread an can be hopefully be given an answer once for all:
and in the end, highly relates to this:
At the very least, I’d say that existing documentation on this obscure and apparently bug-prone topic is not sufficient.
Refs:
(Sorry for the bump, but…)
I finally found a solution!
The error happens if your system has only 127.0.0.1 and its public IPv4 address as ip addresses.
You can fix it by creating a new alias for an interface with a private IP (such as 10.0.0.1).
If you’re using systemd-networkd, adding the lines:
[Address]
Address=10.0.0.1/24
to one of the interfaces defined in /etc/systemd/network/ should be enough to fix the problem.
Ok, this is positively insane…
I have been plagued with this issue for what looks like an eternity now, probably dating back to the move to 2.0; indeed, I’ve since then pretty much abandoned Pydio Cells in favour of simply using a NAS on the local Ethernet — which can also give access to files from the outside world if needed.
The other issue I had was the massive amount of resources consumed by Pydio Cells — which was fixed in the meantime. Pydio 8 (which I still run in parallel), by contrast, only used resources ‘on demand’ — most of the time, doing nothing.
But Pydio Cells still gives access to a handful of repositories that I had not yet transferred… so yesterday I had to launch it at least for a short while in order to copy all the data. As expected, I hit upon this very same issue, even after updating to 2.2.2 – I really hoped that it had been ‘fixed’ by now. BTW, binding to the real IP address gives unpredictable results in my case, since I have two frontends — nginx and Cloudflare! — this confused Pydio Cells too much…
And now I learn that there was nothing ‘wrong’ with Pydio Cells in the first place: it’s just that it requires a special configuration — a most uncommon one! — to properly work.
Oh yes, I’m well aware that the Debian/Ubuntu installation instructions have been updated recently Scroll down to the No private IP Address heading; I believe that was only added by the end of January 2021.
After much reflection, I tried to figure out why Cells needs a private IP address that is not localhost (127.0.0.1) to work. I’m not sure I understand the ‘need’, except that some Linux distributions (Debian/Ubuntu is a good example) consider that localhost is a special address, and TCP/IP calls to it are diverted via a Unix socket (as opposed to an Internet socket). Maybe the Pydio developers have had some difficulties in the past with that (note: depending on the application, using either localhost or 127.0.0.1 can give different results).
While having the microservices running on a private address is not necessarily a bad idea — allowing, for instance, the distribution of those microservices among different instances of virtual servers on a private cloud — I would say that the installation process (e.g. ./cells configure) ought to be a bit more specific. At the very least, the ‘warning’ text ought to be slightly more obvious and point to online documentation — an example would be:
Warning: no private IP detected for binding broker. You need to set up a virtual IP interface with a private address — see https://link.to.documentation — or Cells will give unpredictable results while binding to the public address X.Y.Z.W
That would go a long, long way to fix 99% of the installations which fail due to this mysterious error.
I guess that those who are using Cells as a Docker container and/or some kind of cloud service will have a private IP address anyway, so they will never encounter this error. Because it is an error — and not merely a warning! — since it will be very likely that Cells will not work if the broker was bound to a public IP address… or, at least, that’s my own experience with Cells…
Unlike @Steffo99, I’m not using systemd-networkd, as I’ve been upgrading/updating my own Ubuntu installation for years, and it still includes a lot of ‘legacy’ configurations. That meant sticking to Pydio’s own setup instructions on the above-mentioned external link to get things working as they ought to.
Luckily for me, even if my healthy dose of scepticism and disbelief, those instructions really worked, and I’m now able to use Pydio Cells with all its bells & whistles — so far. without a glitch.
Thanks for the suggestion, I’ll report that in our internal issue tracker and will advocate to include this change in the next version:
Nice to hear 