12

I've just finished upgrading to Ubuntu Server 20.04.1 LTS, and so far, only one issue has come up: When run as user, the beep command returns

beep: Error: Could not open any device`.

Running sudo beep does not work, as expected. After a little bit of research, I have found that no beep group is existent on the system, as expected by the man page. I have tried reinstalling and reconfiguring without success.

To make things even stranger, beep works during boot via rc.local; at some point, however, it stops working and returns the error, thus breaking my rc.local-routine. Also, this command works just fine:

sudo env -u SUDO_GID -u SUDO_COMMAND -u SUDO_USER -u SUDO_UID beep

For clarification: I am running a headless home server that is not connected to any speakers; the simple noise-making-speaker is used for simple feedback during boot and if errors occur that require intervention. My setup used to work fine under Ubuntu Server 18.04 LTS.

Rohit Gupta
  • 348
  • 2
  • 4
  • 11
senthor
  • 319

5 Answers5

5

Adding my user to group input worked for me, ie:

sudo usermod -aG input $USER

The change isn't visible until you log in again (On Ubuntu, I had to restart, not just log out and back in, before a new shell would display the new group in the output of groups.) To see the change within one shell, open a new login shell:

su $USER -
Majal
  • 8,249
Justin Kerr Sheckler
  • 59
  • 1
  • 2
3

One solution suggested in the doc PERMISSIONS.md is to create a system group called 'beep' and then use ACLs to allow members of that group write access to the device.

$ addgroup --system beep

Then create a rule for udev, e.g.

/lib/udev/rules.d/90-pcspkr-beep.rules :

# Add write access to the PC speaker for the "beep" group
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", RUN+="/usr/bin/setfacl -m g:beep:w '$env{DEVNAME}'"

Then you should be able to add users to this group and they can write to the speaker:

$ usermod user_name -a -G beep

Of course the above will only work if you have ACLs turned on. If you can't or won't do that, they have a different suggestion for the udev rule:

# Give write access to the PC speaker only to the "beep" group
ACTION=="add", SUBSYSTEM=="input", ATTRS{name}=="PC Speaker", ENV{DEVNAME}!="", GROUP="beep", MODE="0620"

But this will remove the speaker from being written to by the default system group 'input'--adverse effects are probably negligible since this method is suggested in the documentation.

Angelo
  • 259
2

Making beep work has been a pain for several years. I ended up with this line of code, either as an alias in ~/.bash_aliases or in a script named... well, beep.

/usr/bin/aplay /usr/share/sounds/sound-icons/prompt.wav 2>/dev/null &

Feel free to choose your command-line player and sound.

Majal
  • 8,249
1

Bad solution:

I'm pretty sure this is a permissions issue, but I am not sure how to solve it. I tried creating udev files and groups according to the ArchLinux Wiki, but that wouldn't work.

Then, I changed permissions on the device itself:

sudo chmod 777 /dev/input/by-path/platform-pcspkr-event-spkr

While this does work, it's surely a bad idea to make devices just writeable for anyone.

senthor
  • 319
0

For me, only this solution worked.

sudo sh -c "echo -e '\a' > /dev/console"

sudo can be omitted by /etc/sudoers tuning.

arcadius
  • 1