I have some 40 Dell Latitude E6410s I maintain in my classroom for student use. I have successfully setup and used special 'guest' accounts so the directories are wiped between uses. This scheme worked well for 14.04 LTS. I just tried a trial setup of 16.04 LTS (which in other test environments solves an unrelated annoying problem with some software we would like to run).
The problem is that after the upgrade I can no longer log into the "guest" account. All the administrator and standard user accounts work fine but the automatic "guest" login goes into a loop (as described in other questions, *login the screen clears and the system starts to setup but fails in some way I can't determine and returns to the login screen).
What makes this different is that the 'guest' directory is created on the fly so .Xauthority and local log files aren't visible to me. I can't get much information or apply some of the proposed fixes outlined in the referenced sites for more permanent accounts.
I have changed the 50-unity-greeter.conf file to allow guest logins removing any files that might prevent guest logins.
- Where can I get more diagnostics on what seems to be going wrong here?
- What has changed in the handling of guest accounts? (Yes I have a custom skel directory which is managed by a 'special account' to setup the default environment for the students)
UPDATE: I found the cause of the loop but not answers to the posited questions. The source of the problem in my case which posits another more general one is in the execution on the auto.sh and prefs.sh scripts in the /etc/guest-session directory. These scripts are intended to run ahead of the login so as to do last minute configurations. I have one of each that ran fine under 14.04. The offending instruction is a usermod command:
usermod -a -G dialout $USER
which I use to allow guests to use devices plugged into the USB port. This command worked well in the auto.sh stage of the script under 14.04.
Under 16.04 if I place this command in prefs.sh (where it seems like it should belong) I get the infinite loop problem. If I place it in auto.sh the script executes normally but it is ineffectual (probably because it needs root privilages to change groups.
I found this by trial and error. I still don't know where the login sequence is being logged. I tried checking /var/log/lightdm/ logs and the revealed other minor issues but nothing about the failure mode of these scripts.
