/dev/mem changes permissions back to defaults on system restart!!!


In the end I was going to a the www-data user to the kmem group in order for a memory mapping gpio related program to run called from a webpage so under the www-data user.

The problem is when I go to the /dev/.

$sudo su
root$ ls -al | grep mem

so the listed file details are:-

crw-r----- 1 root kmem 1, 1 date, mem

I do:-

root$ chmod g+w mem

crw-rw---- 1 root kmem 1, 1 date, mem

so now the group has access to the /dev/mem file, which is correct.

Then I restart the tx2 and the permissions revert to the original

crw-r----- 1 root kmem 1, 1 date, mem

Do you have any suggestions about what is going on?


Realize that pseudo files in “/dev/”, long ago, were placed entirely on the file system via the “mknod” utility. However, the bulk of what is in “/dev/” now is generated by the driver itself (possibly edited via udev for naming and permissions). If you change a pseudo file’s permissions, and if that file is generated, then any time the driver is unloaded the file goes away…and when reloaded, the file regenerates with its default permissions. Should you want to change this file across boots, then you will need to create a custom udev configuration.

For examples, see “/etc/udev/rules.d/”. Quite often files here are symbolic links into the permanent files of “/lib/udev/rules.d/”. If an edit is needed, then the file from that location is copied into “/etc/udev/rules.d/” in order to override the original without destroying the original. Symbolic links are often used when there are many optional ways of configuring the device naming convention. You might find some inspiration from this:

egrep -R 'kmem' /lib/udev/rules.d/

Should you find something controlling the naming or permissions aspect you are interested in, just copy that file into “/etc/udev/rules.d/”, and make the edit there. If you don’t like the result, then just remove the “/etc/” version and it will revert back to the default.


Thanks for that and I have managed to copy and updated the udev rules as you stated above.

I updated the line, ~#30

SUBSYSTEM==“mem”, KERNEL==“mem|kmem|port”, GROUP=“kmem”, MODE=“0660”

restart system and checked files permissions:

/dev/mem crm-rm---- 1 root kmem 1, 1, sep 21 09:05 mem

added www-data user to the kmem group

www-data@tegra-ubuntu:~$ groups
www-data kmem

Now I run the program as www-data, but the “mem_fd = open(”/dev/mem", O_RDWR | O_SYNC)) < 0" command still fails yet works under ROOT

Any ideas why a member of the kmem group would not be able to have access to the mem file?



the line

/dev/mem crm-rm---- 1 root kmem 1, 1, sep 21 09:05 mem

should read

/dev/mem crw-rw---- 1 root kmem 1, 1, sep 21 09:05 mem

This shows the device is still owned by user root, group kmem. If your user is in group kmem, then that user can now write, although previously group kmem could only read. It would be very dangerous to open that file to everyone, but perhaps you could add your regular user to group kmem…

For example, if you edit “/etc/group”, and change this:


…to instead be this:


…then user “ubuntu” becomes a member of group “kmem”.

Some people will probably cringe at the idea of directly editing the file, so you could use:

sudo usermod -a -G kmem ubuntu

I don’t know the actual operation/command you are using, so I can’t be sure this is the answer, but it should be closer.