# no sound for non-root users- /dev permissions problem?

## lubond

hi guys,

i've searched these forums on this issue, but my problem seems to go a bit further than what others have had and solved  :Sad: 

when i'm logged in as root (or i've su'd to root) i can hear sound. when i'm logged in as myself i cannot. when i try to play a WAV with aplay i get this message:

```
aplay: main:508: audio open error: Permission denied
```

after forum-searching i made sure of the following things:

```

bash-2.05b# ls -l /dev/audio

lrwxrwxrwx  1 root audio 11 Nov 30 10:23 /dev/audio -> sound/audio

bash-2.05b# ls -l /dev/sound/

/dev/sound/:

total 0

crw-rw----  1 root audio 14, 12 Nov 29 00:50 adsp

crw-rw----  1 root audio 14,  4 Nov 29 00:50 audio

crw-rw----  1 root audio 14,  3 Nov 29 00:50 dsp

crw-rw----  1 root audio 14,  0 Nov 29 00:50 mixer

crw-rw----  1 root audio 14,  1 Nov 29 00:50 sequencer

crw-rw----  1 root audio 14,  8 Nov 29 00:50 sequencer2

bash-2.05b# ls -l /dev/snd/

/dev/snd/:

total 0

crw-rw----  1 root audio 116,  0 Nov 29 00:50 controlC0

crw-rw----  1 root audio 116, 24 Nov 29 00:50 pcmC0D0c

crw-rw----  1 root audio 116, 16 Nov 29 00:50 pcmC0D0p

crw-rw----  1 root audio 116, 25 Nov 29 00:50 pcmC0D1c

crw-rw----  1 root audio 116, 26 Nov 29 00:50 pcmC0D2c

crw-rw----  1 root audio 116, 27 Nov 29 00:50 pcmC0D3c

crw-rw----  1 root audio 116, 20 Nov 29 00:50 pcmC0D4p

crw-rw----  1 root audio 116,  1 Nov 29 00:50 seq

crw-rw----  1 root audio 116, 33 Nov 29 00:50 timer

bash-2.05b# groups luke

wheel audio games users

```

i'm running kernel 2.6.7 and i have emerge'd alsa-lib, alsa-oss, alsa-headers, alsa-tools, alsa-utils and alsa-player. the alsa driver is compiled in my kernel (ie. not as a module). but since the sound works for root i assume this is not the issue.

i read on the forums that for some people upgrading to "udev" fixed their problems. i have done this (as far as i can tell- i'm a bit of a newbie) and i'm still having the same problems. 

furthermore, if i "chown" /dev/audio, /dev/snd/* and /dev/sound/* to "luke" (myself) and make it 777 (just as a test) then i *still* can't play sounds (same error messages). so this tells me that there is soemthing weird going on with permissions in /dev.

also, if i'm logged in as myself this is what happens when i do "ls /dev/sound":

```

bash-2.05b$ ls -l /dev/sound

ls: /dev/sound/sequencer2: Permission denied

ls: /dev/sound/sequencer: Permission denied

ls: /dev/sound/mixer: Permission denied

ls: /dev/sound/dsp: Permission denied

ls: /dev/sound/audio: Permission denied

ls: /dev/sound/adsp: Permission denied

total 0

```

when the permissions are actually 660 and luke:audio. what the hell is going on here?

like i said, i upgraded to udev by emerging the udev ebuild, ensuring that the kernel isn't automounting devfs and added "hotplug" do the boot runlevel (don't know if all this was necessary, but i was following a howto). i have these entries in /etc/conf.d/rc:

```

RC_DEVICE_TARBALL="yes"

RC_DEVFSD_STARTUP="yes"

```

and i have these kernel parameters in my grub config file:  devfs=nomount gentoo=nodevfs

also, i didn't catch the details, but at boot time i saw a message that was something like "configuring system to use udev" and a few other lines. don't know how to look up the logs to find it, sorry  :Sad: 

i hope i've provided all the necessary information for you guys. anyone got a clue what's configuring system to use udevgoing on here?

thanks,

-Luke

----------

## baitken

Are you in the audio group?

----------

## lubond

thanks for the reply.

yes i am in the audio group. see the code listing above where i print out the groups i'm in.

----------

## lubond

problem solved!

well it turns out i'm a moron and not an expert at permissions. i had the permissions correct for the *contents* of the /dev/snd and /dev/sound directories, but not the directories themselves....

this is what i have now:

```

bash-2.05b$ ls -ld /dev/snd /dev/sound

drwxrwx---  2 root audio 0 Nov 29 00:50 /dev/snd

drwxrwx---  2 root audio 0 Nov 29 00:50 /dev/sound

```

whereas before i had this:

```

bash-2.05b$ ls -ld /dev/snd /dev/sound

drw-rw----  2 root audio 0 Nov 29 00:50 /dev/snd

drw-rw----  2 root audio 0 Nov 29 00:50 /dev/sound

```

which is why i couldn't do "ls /dev/sound/*" before as non-root user. sound is now working fine as non-root user.

thanks to anyone who took the time to read my post

----------

## chunderbunny

The proper fix for this is to edit /etc/security/console.perms so that the audio devices have permissions 660 and not 600. This will allow anyone in the audio group to use audio hardware.

----------

## sl70

I started having this same problem all of a sudden around the end of last week. As stated by lubond, the permissions on the /dev/sound directory are 660, where they should be 770 (or 775?).  

The thing is that this did not become a problem until a few days ago. Why?

----------

## lubond

forgive me if you're not a newbie and this question is patronising, but have you recently emerged udev, devfs or PAM? or perhaps something else that has updated some file in /etc and overwritten your permissions config files?

----------

## sl70

No, that's the strange thing. The date on /etc/security/console.perms is last June; /etc/devfsd.conf is October; /etc/security/pam_env.conf is about 3 weeks ago, and I rebooted after that date, so I don't think that's it (not to mention that it doesn't look like there's anything in there relating to device permissions).

Packages I have emerged recently are  pine-4.61-r2, java-config-1.2.11,blackdown-jre-1.4.2.01,  blackdown-jdk-1.4.2.01, gcc-config-1.3.6-r4, gentoo-dev-sources-2.6.9-r6, imagemagick-6.1.3.4, opengl-update-1.8.2, db-4.1.25_p1-r4, avifile-0.7.38.20030710-r1, gnome-themes-extras-0.7, bin86-0.16.13. I don't think any of these would have changed the permissions, would they?

----------

## lubond

i've no idea. i'm little more than a newbie, i'm afraid. hopefully someone more experienced here can help you

----------

## eqxro

I remember I had problems with the perms on my /dev/nvidia*, which left non-roots with no 3D hardware acceleration. In the README it tells you to chmod the devs and update /etc/security/console.perms. This is the excerpt, maybe it can give you a hint:

 *Quote:*   

> 
> 
> Q: OpenGL applications exit with the following error message:
> 
>         Error: Could not open /dev/nvidiactl because the permissions
> ...

 

----------

## Gentree

 *chunderbunny wrote:*   

> The proper fix for this is to edit /etc/security/console.perms so that the audio devices have permissions 660 and not 600. This will allow anyone in the audio group to use audio hardware.

 

Does the same presumably apply to usbscanner devices?

Mine used to work fine a few months back when hotplug needed me to add a script to do the permissions.

All this got blown out by a recent update but hotplug now seems to incorporate the permission settings . Problem is it no longer seems to have any effect, unless it is getting overwritten by something else.

I have modded perm.config for the scanner as you indicate for audio but I get neither the group nor the settings I specify.

My scannner comes up fine at boot (coldplug calls hotplug, ha) but if I plug once sys is up I get 600 root:root and the scanner is only usable as root.

Can you shed some light on what may be goning on.

Thx  :Cool: 

----------

## baitken

 *lubond wrote:*   

> thanks for the reply.
> 
> yes i am in the audio group. see the code listing above where i print out the groups i'm in.

 

Sorry, totally missed that.   :Embarassed: 

Note to self: read before replying

----------

## JJacobsson

I had a similar problem, when user X logged in on vt7 (with gdm) the rights on /dev/sound/* became X:root 660, effectivly "stealing" the devices from anyone else, even from user Y who was already logged in on vt8.

Checking the /etc/security/console.perms file, it had a line that said: 

```
<console>  0660 <sound>      0660 root.audio
```

Scratching my head I wondered wtf was going on, checked the /etc/udev/permissions.d/50-udev.permissions file and it had a line that said:

```
sound/*:root:audio:0660
```

Running 

```
udevstart
```

as root reset the perms to root:audio, but as soon as someone logged in they changed to user:root.

By now I was ready to call my computer insane and have it commited. But something tickled my memory... I rememberd having done chown user.group <somefile> before and getting a warning.... something about the user.group syntax that was deprecated or something. So I changed all the user.group entries in the /etc/security/console.perms file to be user:group. 

And that actualy worked, now when user X log's in /dev/sound/* have X:audio 660 perms. And user Y can keep on rocking to Linking Park or whater flips his/her goat, provided that Y is in the audio group of course...

What would be even nicer tough would be if the right's for the dev's were connected to the currently displayed vt... so when I change to user X's vt user Y's music is silenced etc... That would probably wreak havok with 3d hardware tough.... oh well... someone probably tought about it before me and has solved it already :)

I should add that everything in this post is completely un-scientific. I have very limited knowledge of the console.perms and all this stuff, I just found this to give the results that I wanted.

----------

## JJacobsson

Okey, so obviously I was drunk and/or high when I made that post... some more digging turned out that the permission for my dev's still got whacked whenever I reboot (not that I do that often but still...)

So, it all came down to pam_console, a pam module that does some fancy stuff with device permissions. Unfortuantly, it's not doing the fancy stuff the way I would prefer. First I tried to comment out the pam_console line's in the varius files under /etc/pam.d, and that worked, sortof... the perms stayed correct as long as I dident reboot... Some more digging found that /etc/init.d/bootmisc & /etc/init.d/halt.sh execute pam_console_apply to "reset" the device permissions whenever you shutdown/boot.

And I wasent realy comfortable hacking those scripts, so instead I commented out all the permission rules in /etc/security/console.perms, and I put the pam_console line's back in the /etc/pam.d/* files. Now it work's the way I would like, pam does nothing with device permissions and udev handles everything. And another plus is that I only have to worry about /etc/security/console.perms next time I'm due for a etc-update, instead of bootmisc, halt.sh and pam.d/*.

I would like to add that I also suspected hotplug for a while... but hacking the /sbin/rc script to not use hotplug for udev management resulted in no change what-so-ever.

----------

## butters

I have an even stranger problem: /dev/sound and friends are owned by root:root instead of root:audio.  My settings in /etc/udev and /etc/securityconsole.perms are all set to 660 for root:audio, yet still the permissions get reset every boot to root:root.  As root, amixer runs correctly, but none of my client apps can open the alsa device, and xine-libs cannot link against alsa.  Any ideas?

----------

## <3

can someone please explain what I should do? I'm having the same problem that only the root sure can listen to audio.

my console perms file had this

 */etc/security/console.perms wrote:*   

> <console>  0600 <sound>      0600 root.audio

 

I changed it to

 */etc/security/console.perms wrote:*   

> <console>  0660 <sound>      0660 root.audio

 

and still I don't get sound from non root users.

----------

## BeatJunkie

I just realized that I have the same problem too!  It must have been a while since I rebooted.  :Smile: 

To get it working temporarily, I set permissions as follows:

```
# chown -R root:audio /dev/sound /dev/snd

# chmod 770 /dev/sound /dev/snd

# chmod 660 /dev/sound/* /dev/snd/*
```

I'm in the process now of upgrading from devfs to udev.  After that I'm going to try that pam config modification to see if it works.

----------

## aetius

See:

https://bugs.gentoo.org/show_bug.cgi?id=72119

and

https://bugs.gentoo.org/show_bug.cgi?id=31877

That might help.

----------

## BeatJunkie

Okay, I switched my system completely to udev.  Specifically I'm running:

mm-sources-2.6.10-mm1

udev-050

pam-0.77-r4

I'm running completely with udev, and have removed devfsd.  Prior to doing this upgrade I had set the permissions as per my previous post, and modified /etc/security/console.perms as per earlier posts here.

So far so good.  Not sure which piece of the puzzle fixed it.  If I were to troubleshoot again, I'd probably start by setting permissions, editing console.perms and upgrading to pam-0.77-r4.  

Switching from devfs to udev isn't trivial and will probably break things, so I would only recommend trying it after reading all about it at: http://www.gentoo.org/doc/en/udev-guide.xml before making the switch.

Cheers.

----------

