NoMachine Support

Your questions answered

Knowledge Base

Searching in: Articles & FAQs
Filter the search results
Applies to:
Last update:
Searching in: Articles & FAQs
ID: AR05K00674
Applies to: NoMachine Server
Added on: 2013-05-17
Last update: 2020-06-01
How to solve possible printing problems with NoMachine 4 or later and CUPS 1.4 or later

Some users may experience problems when try to connect a local printer on remote or print a document from the session to the local printer.

Symptoms may vary from the unability of connecting the local printer inside the NoMachine session to the impossibility of printing a document from the session to the local printer and getting for example only a blank page.

This may happen when the NoMachine server is on Linux or Mac and the printing subsystem is CUPS 1.4 or later.

With CUPS 1.4 or later, to ensure that users are able to connect a printer from locale to their NoMachine session on Linux or Mac, it's necessary that the user already belongs to the CUPS System Group on the NoMachine server host.

That's because, to add a printer to the CUPS system, the 'lpadmin' command line tool has to be executed by a user who belongs to the CUPS's System Group, which can be for example 'lpadmin' on Ubuntu, 'sys' on Fedora, RHEL and CentOS distributions and _lpadmin on Mac.

The solution is to add the user to the CUPS System Group, as explained below in the example for CentOS 7.

In other cases, e.g. on SUSE distributions like SLED 15, the lpadmin group may not exist. It's therefore necessary to create that group and then add the user to the CUPS System Group. See the next example for SLED 15.

Check the man page of CUPS on your OS for retrieving path to the CUPS configuration file. For example man page for Ubuntu 16.04, 18.04 and 19.10  reports for cups-daemon_2.2.8: 

       The  cupsd.conf  file  configures the CUPS scheduler, cupsd(8).  It is normally located in
       the /etc/cups directory.  Note: File, directory, and user  configuration  directives  that
       used  to  be  allowed in the cupsd.conf file are now stored in the cups-files.conf(5) file
       instead in order to prevent certain types of privilege escalation attacks.



Example for CentOS 7 (add the user to the CUPS System Group)
The example below applies to CentOS 7, commands have to be executed on a terminal on the NoMachine server host or node in case of a multi-node environment:

1. Retrieve the CUPS System Group from the CUPS configuration file, namely /etc/cups/cupsd.conf.
The related entry looks like the following:
SystemGroup lpadmin sys root

2. Check if the user is in any of the CUPS System Group (e.g. 'sys' on CentOS 7), by running:
id user_name

For example, if the user is nomachine:
id nomachine

Output will be similar to:
uid=1000(nomachine) gid=1000(nomachine) groups=1000(nomachine),7(lp)

In this case user 'nomachine' doesn't belong to the 'sys' group.

3.  If user 'user_name' is not in the CUPS System Group, you (as administrator) need to add the user to this group by running:
sudo usermod -G group_name user_name

You may specify multiple groups as a comma-separated list. For example:
sudo usermod -G sys,lp nomachine

4. Verify that the user has been added to the CUPS System Group by running:
id user_name

For example:
id nomachine

Output should be now similar to:
uid=1000(nomachine) gid=1000(nomachine) groups=1000(nomachine),3(sys),7(lp)

5. Log out and start the NoMachine session again.

Example for SLED 15 (add the lpadmin group and add the user to the CUPS System Group)

1. Verify that the lpadmin group does not exist:
 cat /etc/group | grep lpadmin

2. Add the lpadmin group to the system:
sudo groupadd lpadmin

3. Add the user to the freshly created lpadmin group:
sudo usermod -a -G lpadmin <username>

4. Verify that the lpadmin group was created and the user now belongs to that group by executing again:
 cat /etc/group | grep lpadmin

5. Edit the /etc/cups/cups-files.conf file and add the lpadmin group to the SystemGroup, for example:
SystemGroup lpadmin

6. Reboot the machine.