Replies: 12 comments
-
When the systemd service is running and generates that authentication prompt - what is the actual user running those service files? That 'user' may not actually have access to your configuration files under 'root'. Generally - as a security aspect - you should not be running services as root ... but you are free to do as you want.
There is only 1 'root' login ... 'root' is 'root'. What is probably happening here is that however you are starting the services / enabling the services - and is probably something unique to your chosen distribution. It may be running | enabling the services as a different user.
This is curious .. if you are getting But .. CentOS 7 does not support If Nethserver is trying to do something different in enabling systemd services - that means the systemd package provided by Nethserver is not the same as what is provided by CentOS. I suspect a number of items here going on for you:
If this does not work - this is not an issue I can assist with any further - and you need to speak to the folk who provide support for your chosen distribution: https://community.nethserver.org/categories |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, that is about what I had gotten to... just to be clear, I wasn't using the Nethserver interface for setting this up but rather using the CLI to going through the process that you've documented, and clarified above. NS does have the ability to control the systemd services but only if you explicitly set it up. I think I've tried the suggestions above... off the the NS forums I suppose! |
Beta Was this translation helpful? Give feedback.
-
|
@tdcockers The combination of those changes will help identify what is going on in a systemd scenario to work out what the application is doing in terms of interpreting where the config file is located and why it cant find it. If you can do this testing and provide the logs this will go a long way to helping you resolve this issue. |
Beta Was this translation helpful? Give feedback.
-
|
Hey mate, thanks for checking back in. I've run the service with the line: Running the onedrive line with the debug output manually works as expected. Service file is in /lib/systemd/system/. I guess there is some sort of permission issue going on, but I just can't see where it is. Haven't had any solutions offered from the NS forums that have helped yet either :( |
Beta Was this translation helpful? Give feedback.
-
|
@tdcockers What happens if you take all the redirect out, leave verbose, and in the 'config' file enable logging The verbose systems logs should show what the application is calculating where to find the config |
Beta Was this translation helpful? Give feedback.
-
|
No, nothing at all written, and if the file doesn't exist before it isn't being created either. I've removed the redirect, enabled logging in the config and set the log directory to /var/log/onedrive/scans. Starting the service logs nothing, starting manually via command line logs the following: Could it possibly be a permission issue on the binary rather than the config/logging/share directories? |
Beta Was this translation helpful? Give feedback.
-
|
@tdcockers |
Beta Was this translation helpful? Give feedback.
-
|
@tdcockers
Compile, Install and Authenticate systemd setup I suggest that you strip things back to basics first ... and work from there. |
Beta Was this translation helpful? Give feedback.
-
|
@tdcockers root systemd in debug mode custom systemd in debug mode The difference here is that for whatever reason, extra As such, please can you test the following PR: To run the PR, you need to run the client from the PR build directory: To install the PR, you will need to perform When running the PR, your version should be: |
Beta Was this translation helpful? Give feedback.
-
|
I literally just figured this out 45 seconds ago!! Will test the PR momentarily. |
Beta Was this translation helpful? Give feedback.
-
|
Hey mate... I believe the PR you've just pushed through is working perfectly, I'm syncing 4 different sharepoint libraries with no issues at all, and all 4 services started on boot. Thanks for persevering with my edge case to find a resolution despite your initial assessment being an environment specific issue. |
Beta Was this translation helpful? Give feedback.
-
Glad this is now sorted and you are operational, the PR is merged into 'master', also thanks for the sponsorship.
Without seeing any logs or evidence of what is going on, and with this particular issue - with something that is known to work - esp if using user or root home directory (which you indicated you were initially using as per above - It was not until later on where your posts switch to using |
Beta Was this translation helpful? Give feedback.
-
I'm having issues getting the client to autostart on a Nethserver instance, which is essentially a web interface overlay for a headless Centos 7 install. I'm almost certain my issues stem from me not understanding how linux authentication/privilege escalation work, so hopefully the answer is simple enough.
Client is installed, running, authorised and manually syncing happily (sharepoint, 4 x libraries/instances) using --confdir and --monitor, all from 'root' login to the server (ie no sudo).
When I try enable the services, using 'systemctl enable/start custom.service' fails and the log shows it asking for authorisation again (configs are under /root/.config/onedrive/sharepoint/{various}). I presume it is running in a different 'root' profile or something like that?
The server doesn't have any other user accounts on it. I tried a various assortment of ways to run it as a user service using the root account as well just in case, but keep getting errors along the lines of failed to connect to DBus, no such file.
Any tips? Thanks.
Beta Was this translation helpful? Give feedback.
All reactions