Cannot authenticate to FreshRSS self-hosted instance from NetNewsWire iOS using dedicated "FreshRSS" login

[thorrrr]

Hi there,

I'm running FreshRSS via the linuxserver/docker-freshrss container on my local network (192.168.23.100), and I'm trying to connect to it using NetNewsWire on iOS, using the new built-in FreshRSS login option (under "Self-Hosted").

Environment FreshRSS version: Latest (Docker: linuxserver/freshrss)

iOS App: NetNewsWire (latest release, iOS)

Access point: http://192.168.23.100/api/greader.php

Authentication method: Web form (traditional)

“Allow API access” is enabled

Issue Whenever I try to log in via the iOS app using:

Username: thorrrr

Password: ******

API URL: http://192.168.23.100/api/greader.php

I receive the following error: “Unauthorized”.

I've confirmed that:

http://192.168.23.100/api/greader.php works and loads in a browser.

curl -u thorrrr:password http://192.168.23.100/api/greader.php/reader/api/0/user-info gives 401 Unauthorized or fails.

Port 80 is open, and I can access FreshRSS from the same iOS device in Safari.

I’ve also tried:

Simplifying the password (alphanumeric only)

Disabling and re-enabling API access

Using both http and https variations

Question Is there any specific requirement or configuration that NetNewsWire expects for the “FreshRSS” login to succeed? Does the Google Reader API (greader.php) require an alternate auth mechanism, or is this a known issue with FreshRSS containers lacking certain auth modules?

Thanks for any help you can provide. Let me know if you'd like full logs or environment variables from my container.

[thorrrr]

Addendum: Potential Volume Mapping Conflict (Unraid)

Just to add further context — I’m running FreshRSS in an Unraid container using the linuxserver/docker-freshrss image. The container has /config mapped to /mnt/user/appdata/freshrss on the host.

This may be relevant, because based on how the container is structured, FreshRSS seems to install itself under /config/www/freshrss, meaning the entire application lives inside the mapped config volume.

That made me wonder: Does mapping /config over /mnt/user/appdata/freshrss interfere with FreshRSS’s ability to expose or serve greader.php and other API files (like /api/greader.php)?

In my current setup, that file doesn’t exist at all (404 from browser + confirmed missing in container shell). I suspect the /config volume might be replacing parts of the default install if mapped too early or if it's pre-populated with incomplete files/folders.

Let me know if this mapping approach needs to be different for the API endpoints to work correctly. Thanks!

[endquote]

@thorrrr Maybe you did this already, but in addition to enabling API access on FreshRSS, you have to set an API password under Settings > Account > Profile > External access via API.

[brentsimmons]

Is this still a bug or have you resolved it?

[bastos]

Is this still a bug or have you resolved it?

I have the same issue. I'm using http, not https, maybe this is the problem 🤷

[bastos]

Is this still a bug or have you resolved it?

I have the same issue. I'm using http, not https, maybe this is the problem 🤷

Nope, my issue was solved by reading this comment.