Education - One-Shot script to Set up Automatic Student Drive Mapping + More

This is my first post to this forum, and I have had to trawl through the internet and perform a lot of testing to make this just work.

The original aim was to simply mount any student's share when they log in; a diabolically difficult effort due to an appalling lack of documentation.
Now, you may think, "Oh, that will be simple." Perhaps it is, but I sure couldn't find an adequate answer anywhere for a couple of years.

So, after finally making that work, a student can log in via Active Directory [MS or AD 4], and have all their personal SMB shares for their ID number mounted in their home directory as folders.

Additional elements have been added over time, to make this a mostly one-shot script, with some manual entry.

Some aspects still being worked on are printers, but that is not as hard as it used to be. I expect this will be different enough in each environment; you would need to customise this anyway.

The idea is, when setting up a machine, you join it to the Active directory during installation [otherwise, this won't work.]
You then perform all updates and reboot.
You acquire the script collection, with your customisations and special required files for installation [such as Chrome, Google Earth, etc], and run

I tend to keep the entire deployment on a USB stick and extract a tar.gz to a setup account on the target PC, chmod +x the deployment script, and then run it.

It's not perfect, there are still things which need to be done by hand, and some installers will prompt you for input; like KRB5, and the proprietary tools with fonts etc.

Hopefully, people will find this useful. It's not meant to be complex. Also, make sure you check and edit every file for your environment.

Further details and scripts at GitHub:


Students have, indeed asked about this very subject on this forum.


Thank you for sharing this! I'm sure there's lots of good stuff we can all learn from this.

A few Screenshots of the result of running deploy:

Login Screen:

Desktop as First Seen:

Clicking OK for Chrome Defaults:

Showing Drives Mounted For Student:

Showing ACLS Working:

Showing Their PDrive Share:

The important factor here is, that this is all using Kerberos Tickets. Access Control Lists work fine on the target shares automatically and there is no need to mount manually or enter a username and password; it is all passthrough. They have access to the same shares as a Windows machine does.


As the script develops, I am also adding hint sections for scenarios I have come across. The first major one is a hint on handling the network manager when the user is a student on a laptop; where they want to connect to home wifi.

Most students will not go to settings->WiFi to connect, which is a working method for a non-admin user. Instead, they go to the network manager, which demands elevation. The hint provides a method for changing this in the configuration so that normal users can make these changes. It is further augmented so that it would be used in a crontab, so that future updates would be corrected in the event that the altered configuration files are replaced.

1 Like

As time passes, I've been testing other scenarios and issues with a 60-machine deployment I am putting in place for the beginning of next year.
Printers have been automated for these machines, but the issue is that such a configuration is environment-specific. However, I might include some examples in the public script, as a hint; is there much demand?

I'm also interested in what other people would have liked to have had; questions and tips are welcome.

I notice a modest amount of clones of the GitHub repository when updates are made. I'm interested in hearing back from anyone using this and if there are areas they'd like improved or explained in more detail. It's preferable to working in limbo, where I'm guessing what people need while putting in things used in our environment :slight_smile:

I don't know about Chrome's backend but for any student with a Vision Impairment the best browser is Firefox as it works best with Screen Readers, such as Orca. The other point to make is that Educational establishments should be running Firefox ESR as it is the only version of Firefox that can be 'locked down'. When I was working as a VS Technician in School and supporting students in College, Chrome did not work well at all with any screen reader. The best browsers for screen readers then were Internet Explorer and Firefox. I had to relay this information to the QTVI's (Qualified Teacher for the Visually Impaired) supporting the student.
One of the principal challenges will be are "Will the applications available meet the needs of the school's/national curriculum."
[On a side note we had some off-line notebooks one of which I used Zorin 10 to edit videos on i-Pads (before Apple locked them down with new updates). I was able to connect to the network without any intervention from IT and was able to install printer driver for Canon UFR-III driver for the mono laser printer in Classroom in main building, and also Kyocera MFD that sat in our main office, also in different building - I just had to print off the settings info off the Canon to find it's IP address, and on the Kyocera, just scrolled through the LCD screens to find the IP address. I should add that the Kyocera MFD was not school equipment but the services. Zorin was pretty good at connecting to Printers!
I think the only potential problem with printers is if schools deploy printers by a manufacturer who doesn't support the Linux kernel (drivers).

I could certainly add a line for Firefox ESR into the script as an option.

The thing about Chrome, in this case, is we're a Google Workspace school, so it integrates quite nicely with what we are running + we do get the control via the Google Workspace Admin policies [Chrome has a very comprehensive configurable user/chrome policy for student/teacher accounts, including various levels of lockdown and control. This does extend into MDM.]

The printer support is very nice in Zorin :slight_smile: I'm just looking for sensible options for automatic installation via the script; I do have it working over at this site and did automated deployment for 62+ machines in 2 labs, but that is via a couple of lines for lpadmin. The chief issue is that adding printers with drivers is going away, so it is a bit of a major; especially in terms of PaperCut, where the target is a virtual queue requiring a driver capable of talking to Fujifilm MFDs properly.

The other problem with printing is that this is a mixed site, so Mac/Windows/Linux. Finding a modern but compatible method for printing on CUPS via PaperCut is a tad... difficult. I know there are solutions, but I need to sit down and review what I need to shift to, and I certainly don't want a Windows print server.

The issue with any GNU/Linux OS that uses Systemd has autodiscovery enabled. It needs to have the auto discovery stopped, then disabled. This will prevent multiple instances of printers being present on machines.

This should help with the print server side of things:

Auto discovery is disabled as part of the script, including the broadcast method from CUPS, which has worked quite well in our use-case.

At the moment, the biggest issue with PaperCut, is the NTLM authentication mechanism. The printer server itself is using spoolss, but my preference is to move to a non-smb solution; and remain compatible with Windows/Mac/Linux.

After finding a bug and checking on Veyon versions, I found Veyon was now available as a single metapackage; and as a more recent version.

The script has been updated to fix the student login and out bug, which prevents the Veyon server and worker processes from running and, thus, the Veyon master program from seeing and controlling the student's desktop.

If you used a prior version of the script on a client machine, you can remove the old packages and install the new metapackage on a previously deployed client by performing:

sudo apt remove veyon-service veyon-plugins

Then install the new version with:

sudo apt install veyon

I am in the process of testing script changes with Zorin 17.1 Education. Some have already been committed, with instructions depending on if it is being run with 16.3 or 17.1.

At the moment, other than the specific changes related to GDM, which the end admin does, the critical area of concern is making Veyon function. If you do not use Veyon, you are good to go; otherwise, be aware that this is being worked on.

Classic case of Veyon not working on Wayland, but fine on X11. This is not necessarily a bug, but I'll see if I can find an optional workaround which could be applied via the script. Hopefully, Veyon will have a version supporting Wayland in the soonish future.

Optional workaround is now in the script, and is a simple way of switching to X11 by default:

Veyon-specific configuration changes for Zorin 17 - uncomment as needed.

#sudo sed -i 's/# WaylandEnable=false/WaylandEnable=false/' /etc/gdm3/custom.conf # Veyon does not support wayland, so switch all systems to X11

The above change only takes effect on reboot.