>
>
"That was already clear from your last post."
I have no idea what you're saying was clear from the previous post. The fact
that it was a sogod error? That could not have been clear from my previous
post because I had not seen a sogod error or made any mention of sogod
reporting an error, and a 502 doesn't immediately imply that. Or maybe what
was clear to you was that my nginx conf was not likely the cause of the 502.
But just quoting an entire paragraph in which I said multiple things and saying
"that was already clear" doesn't really specify what you're talking about, and
making that observation doesn't add any new information, so I get the sense
helpfulness wasn't the motivation in saying that.
"No, it isn't. And that's the problem."
Uhhh.... Yes it was. I didn't show the output from ss or top, but I verified
it myself. Running systemctl also showed it as active. It just displayed the
dictionary error and the failure to read the config error, and then reported
that it was running. Don't know what else to tell you.
"sogod aborts because your sogo.conf is malformed. Is the content of the file
enclosed between '{' and '}'?
Wrong again... I actually shared my file, and yes it's enclosed in '{' and '}'
and satisfies the GNUstep standard for an NSDictionary (which was the case even
before I caught up to what an NSDictionary is). My sogo.conf wasn't malformed
at all. In my last reply to this thread, I even explained what I did to solve
this issue. It was purely a matter of faulty ownership. Multiple online
sources claimed that /etc/sogo/sogo.conf should be owned by sogo:sogo, but for
me that was causing the sogod error that broke my ability to connect to the
site. For me, it needed to be owned by root:root. Simple as that. My
sogo.conf is actually fine, though may still need improvement when it comes to
tackling my next issue of getting the SQL auth working. But the site is
loading fine now, which was the whole point of this thread (which I have marked
as SOLVED since my last response)..
"If that's not the problem, post your sogo.conf here. Someone will likely
spot the error."
I already did in my very first message (top of the thread). In fact, my first
message contained my entire setup and all relevant configs, so nothing should
have been missing. Not that I don't appreciate anyone who takes the time to
respond to me, but you come off a little like you didn't really read much of
what I explained lol. But it's all good, it's up and running for me now and I
figured it out.
--
Secured with Tuta Mail:
https://tuta.com/free-email
Oct 8, 2025, 04:54 by [email protected]:
> Okay, I finally figured out the cause of the sogod error. From the Arch wiki
> on setting up sogo (and a couple other places), I had picked up on the
> instruction to set the ownership of /etc/sogo to the sogo:sogo user and
> group. This made sense to me, considering sogod runs as the sogo user,
> however it turns out that's what broke it for me. Returning ownership of
> /etc/sogo/sogo.conf to root:root enabled sogod to access the config again,
> even though sogod is running as the sogo user. I'm not sure why this is the
> case, but I guess in my setup, /etc/sogo needs to be owned by root, and the
> permissions need to be 0755 for /etc/sogo and 0600 for /etc/sogo/sogo.conf
> and 0700 for /var/spool/sogo. I also have /var/run/sogo and /var/spool/sogo
> owned by sogo:sogo, per the Arch wiki's instructions, though I'm not sure how
> strictly necessary that is given the wiki was incorrect about the ownership
> of the sogo config (at least for my setup), so it's possible those can stay
> owned by root and still work fine. But with things setup that way, I am now
> able to load the sogo webmail site. But that doesn't mean I'm all setup and
> ready to go just yet. I still have the issue of setting up the MariaDB
> database and getting sql authentication working correctly, but I'll open a
> separate thread for that issue.
>
> Cheers!
>
> --
> Secured with Tuta Mail:
> https://tuta.com/free-email
>
>
> Oct 8, 2025, 03:16 by [email protected]:
>
>> I actually just caught onto that shortly before your reply. I kept
>> researching and messing around with the nginx config, reviewing tons of
>> examples online, and I started to get a creeping hunch that it probably
>> isn't the nginx config that's been the problem, which may be why I've been
>> confused about re-writing the config exactly the way it had been back when I
>> briefly had it working, and yet I couldn't get it to work again. I finally
>> caught a sogod error in running "systemctl status sogo," and so now I'm
>> aware it isn't the nginx config, but sogo isn't actually running properly,
>> and now I've turned my attention toward figuring out why. It appears that
>> the sogod service is running, but with the following error:
>>
>> Oct 08 01:44:55 host.{REDACTED}.{TLD} systemd[1]: Starting sogo.service -
>> LSB: SOGo server...
>> Oct 08 01:44:56 host.{REDACTED}.{TLD} sogo[11780]: * Starting SOGo sogo
>> Oct 08 01:44:56 host.{REDACTED}.{TLD} sogo[11851]: 2025-10-08 01:44:56.073
>> sogod[11851:11851] File NSDictionary.m: 671. In -[NSDictionary
>> initWithContentsOfFile:] Contents of file '/etc/sogo/sogo.conf' does not
>> contain a dictionary
>> Oct 08 01:44:56 host.{REDACTED}.{TLD} sogo[11851]:
>> <0x0x560409ae2410[SOGoStartupLogger]> Cannot read configuration from
>> '/etc/sogo/sogo.conf'. Aborting
>> Oct 08 01:44:56 host.{REDACTED}.{TLD} sogo[11780]: ...done.
>> Oct 08 01:44:56 host.{REDACTED}.{TLD} systemd[1]: Started sogo.service -
>> LSB: SOGo server.
>>
>> I'm not really sure what's meant by the lack of a dictionary (looking over
>> the documentation on how to setup sogo.conf, I don't think I'm missing any
>> of the really important config values, although it's possible I've
>> misconfigured one or two of them. I double-checked that the sogo user has
>> permissions to access the config file, with 0755 sogo:sogo perms on
>> /etc/sogo and 0644 sogo:sogo perms on /etc/sogo/sogo.conf. Despite having
>> the debug values enabled in sogo.conf, no info is getting logged to
>> /var/log/sogo/sogo.log (that only seems to happen when sogod runs properly).
>> And I have no idea what I did the other day that broke my ability to
>> connect (I assumed the entire time that I had an incorrect nginx config), so
>> I'm not really sure how to troubleshoot this problem beyond what I've
>> already checked. So now this thread has turned into a sogod troubleshooting
>> attempt rather than an nginx one.
>>
>> --
>> Secured with Tuta Mail:
>> https://tuta.com/free-email
>>
>>
>> Oct 8, 2025, 03:05 by [email protected]:
>>
>>> 08.10.25, 04:02 +0200, gluonman ([email protected]):
>>>
>>>> The error appearing in /var/log/nginx/{REDACTED}.{TLD}/webmail/error.log:
>>>> 2025/10/07 20:53:57 [error] 923#923: *3 connect() failed (111:
>>>> Connection refused) while connecting to upstream, client: {REDACTED},
>>>> server: mail.{REDACTED}.{TLD}, request: "GET / HTTP/1.1", upstream:
>>>> "http://127.0.0.1:20000/ <http://127.0.0.1:20000/>", host: "{REDACTED}"
>>>>
>>>> The error appearing in my web browser when attempting to visit the site:
>>>> Error code: 502 Bad Gateway
>>>>
>>>
>>> Looks like sogod simply isn't running. Check why / start it.
>>>
>>> --
>>> Regards
>>> mks
>>>
>>
>>
>
>
