Adding an Olares user creates a platform account with a role and resource quota. It does not automatically grant access to every installed app. Check three things for the app the person needs: its entrance policy, its sign-in rules, and permissions for the resources inside it.

Some apps are shared with every member of your Olares. Others keep their own accounts, roles, or sharing settings that you set up separately. Olares app access depends on the specific app and version, so check that app before you promise a new user they can use it.

Does Adding an Olares User Grant Access to Every App?

The Olares Open WebUI multi-user guide illustrates all three layers. The entrance is owner-only by default. The documented setup changes it to Public, creates separate Open WebUI accounts, and shares configured models. Creating an app account alone does not make an owner-only entrance reachable.

A family member or coworker can sign in to Olares successfully and still be blocked at the app entrance, at app login, or when selecting a model. Identify which layer fails before changing roles or resources.

The guide does not say which Olares OS or Open WebUI versions it covers. Treat it as one documented example of how app access can sit apart from platform sign-in. It is not a promise about your installation, and it is not a rule for other apps.

What an Olares Account and Role Actually Establish

An Olares account sets who the person is on your system, their platform role, and how much CPU and memory they get. Our team account documentation says the new user’s Olares ID must be on the same domain as the administrator’s. It also says only a Super Admin can give someone the Admin role.

That role is a platform role. It describes the person’s standing on Olares itself. It is not an admin role inside Open WebUI or any other app, and it does not automatically create one. If an app has its own admin, editor, or viewer roles, those live in the app.

The CPU and memory quota is also a platform setting. You set it when you create the account and can change it later. A bigger quota gives the user more resources to run things. It does not give them permission to open an app or see its data.

GPU use is a third, separate layer. GPU resources are assigned to specific applications rather than user accounts. Because user quotas, GPU allocation, and app permissions operate independently, granting GPU capacity to an app does not determine which users can log into it. When access is the issue, check the app’s own permission settings instead of adjusting system quotas.

Why App Access Can Differ

Apps on Olares do not all handle users the same way, so platform sign-in does not guarantee uniform app behavior. For example, our documentation describes shared applications as centrally managed services that cluster members can access without separate copies. That documentation ties this unified architecture to Olares 1.12.6.

A shared application can integrate its login with Olares, but that integration does not establish every permission inside the application. Check the installed app’s documentation for how its users, roles, and shared data are managed.

Layer	Question	What to check
Entrance	Can the person reach the app?	Olares entrance policy and the app’s documented sharing setup.
App login	Can the person sign in?	Integrated login or a separate app account.
Resources	Can they use the intended content?	App roles, groups, and explicit model/document sharing.

For the documented Open WebUI setup, the Public entrance makes the app reachable without the owner-only Olares entrance check; the app’s own authentication becomes the main access control. Review that exposure and configure app accounts before inviting users. Follow the documented entrance setup deliberately, rather than either skipping it or treating Public as a universal fix for every application.

A working Olares login confirms platform access. App reachability, app login, and access to a particular model or document still need their own checks.

What to Check for the App You Need

Work through the specific app and versions in front of you. Then confirm access from the user’s side instead of trusting what the admin view shows.

1. Write down the versions. Note the installed Olares OS version, the app’s name and version, and the user’s platform role. Documented access behavior applies only to the versions it was written for.
2. Check the entrance and sign-in model. Read the app’s documented access setup for your version. Confirm the intended user can reach the login page, then check whether the app uses Olares sign-in or a separate account. For Open WebUI, include the entrance step in the multi-user guide.
3. Check for an app-level assignment. Look for any user, role, group, or sharing step the app requires. Examples include creating an app account or sharing a model. If the docs require one, set it up inside the app. Do not expect a role change or quota change in Olares to do it for you.
4. Confirm the result as the user. Test entrance reachability, app login, and a permitted action in that order. If a check fails, return to that layer. An installed-app icon or a larger CPU quota does not prove the user can open a model or document.
5. For Open WebUI, test allowed and blocked resources. Sign in with the intended regular user, confirm a shared model answers a test message, and check that a model or knowledge base that was not shared remains unavailable. Use a second account with different permissions if possible. This is a verification checklist, not a claim that this article tested your instance.

FAQs

What does a new user need before I can add them to Olares?

They need an Olares ID on the same domain as the administrator’s, and your system needs enough free resources to give them. Our team account documentation lists a minimum of 1 CPU core and 3 GB of memory per account. Create the account under Settings > Users > Create account. You will get an activation link and a one-time password, and you can check activation status under Users.

Can any Admin make another user an Admin?

No. Only a Super Admin can give someone the Admin role on Olares. Keep in mind that this is a platform role. If the new user also needs admin rights inside a specific app, set that up through the app’s own role or user settings.

Will raising a user’s CPU or memory limit help them get into an app?

Not for a permission problem. You can change an existing user’s limits under Account info > Modify limits, and that changes how many resources they get. It does not create an app account or share app content with them. Raise limits when the app’s documentation calls for more resources, not as a fix for missing access.

Does assigning a GPU to an app give a specific user access to it?

No. GPU resources are assigned to apps, not users, so a GPU assignment does not decide who can use the app. Be careful with GPU changes on a shared system. Switching a GPU’s mode stops the apps running on it and removes their GPU assignments, so plan for that interruption before you make the change.