Thanks for Epoptes !
We are using Edubuntu 12.04 with the Epoptes installed by defualt. While there was no issue in using Epoptes as any user declared in the /etc/group file within the epoptes group, we have experienced issues in using alternative group and in particular groups obtained though a samba server. The following describe the context :
The /etc/default/epoptes file has been modified to include the statement SOCKET_GROUP=net_remoteview
The net_remoteview group does not exist on the local machine but is coming from a samba server on the newtork mounted as a PDC. The group can be seen by the getent groups command.
A user which belongs to the group net_remoteview is looged on the Edubuntu station and launch epoptes either from the GUI or from a command line. epoptes does not launch and comes out with the following error : 'An error occured while connecting: 13: Permission non accordée.'
In order to test if it was not only a samba issue, a local group called epoptes_test has been created and the /etc/default/epoptes file has been modified to include the statement SOCKET_GROUP=epoptes_test. After logging again a user belonging to that new group, launching epoptes leads to 'An error occured while connecting: 13: Permission non accordée.'
We would be very grateful if you could help us to locate and solve the issue.
Best regards,
SmoothFroggy
> After logging again a user belonging to that new group, launching epoptes
> leads to 'An error occured while connecting: 13: Permission non accordée.'
After every group change, you need to restart the epoptes service, which uses the group to create its listening socket in /var/run/
sudo service epoptes restart
So, first, check if the epoptes service is running when your computer starts (using a samba SOCKET_GROUP for epoptes):
sudo service epoptes status
Then, try restarting epoptes:
sudo service epoptes restart
And finally, try running epoptes:
epoptes
If that way you're able to start epoptes, this means that the epoptes service starts before samba starts.
In that case, check for the workaround mentioned in comment #12 of this similar bug report with epoptes and Likewise Open (LDAP):
https:/