Failed to open /dev/mem, try checking permissions.

Question

Hi,

I've received an error:

"Failed to open /dev/mem, try checking permissions.

Failed to map the physical GPIO registers into the virtual memory space.

bcm2835_init: mmap failed (SPI0): Bad file descriptor"

- It happens when I made a "MAKEFILE" using the Geany.

Blink: arduPi.o

g++ -lrt -lpthread blink_test.cpp arduPi.o -o blink_test

- Compilation was successful but when I ran it usig

./blink_test

-I received the above error

-But when using the terminal running

sudo ./blink_test

-It ran flawlessly, might be in the Geany?

Please help, thanks

mconners · Accepted Answer

The answer is right there in your post.

When running the program (./blink_test) as a normal user , you get the message: Failed to open /dev/mem, try checking permissions

when you run it using sudo (the super user), you don't get the error

what this means is, the dev/mem 'device' is not accessible to the normal user, but it is accessible to the root (sudo) user

You will either need to open up the permissions (which is not a good idea, they'll probably get changed on reboot anyway) or continue to run the program as root, using sudo.

If this is just a toy program to help you learn, typing sudo is probably not too bad, but if this were to become a deployed system with untrusted users, you would probably want to learn a lot more about Unix system security.

There are a number of ways and methods to accomplish this, but unless your goal is to become a unix system administrator, you probably don't want to learn them just to get a program to run on the pi.

Mike

mconners · Answer

BTW, I replied without knowing what Geany was, apparently it is a text editor. No that is not the cause of your problem. The problem is purely a case of you trying to access a system resource (/dev/mem, and the gpio that is mapped via memory) by a user that doesn't have adequate permissions.

http://www.amazon.com/Nutshell-Fourth-Edition-Arnold-Robbins/dp/0596100299/ref=sr_1_1?ie=UTF8&qid=1389624450&sr=8-1&keywords=unix+in+a+nutshell

This is a great book for beginning unix users, and really even advanced unix users.

Mike

iagorubio · Answer

Hello Clemzky,

As Michael told you the only problem is to access /dev/mem you need root permissions.

As we are talking about playing with your Pi in a single user environment, there are some tricks that would allow you to directly use your program. Take into account that to use those solutions in a full-fledged multiuser Linux or Unix system would have security implications.

The easiest way to use your binary directly is to make it suid root. That means that the program will always be run with root permissions no matter who runs it. It's how, as example the "ping" command was usually set in Linux as its normal operation requires root permissions.

To setuid your program you use the command:

$ sudo chmod u+s blink_test

The main problem with this approach is if another user can write in the file, it can modify it and alter its behavior to make it do something completely unrelated with root permissions. For this suid programs in Linux/Unix are not usually writable but for the root user.

If you use this approach, you would most likely add this command to your makefile to after the link stage it sets the suid bit on your file.

Another easier approach is to alias your_file to "sudo your_file". That means that each time you class "your_file" the shell will change that command for "sudo your_file".

That's how it uses to be setup the "ls" command as example, as most people like to see the file colors and that needs a command line switch "ls --color=auto", so in most systems "ls" is aliased to "ls --color=auto". The good think about this solution is it have no safety concerns. It just works for your user and is just a helper to avoid typing "sudo" each time you want to run your file.

To know your actual aliases just type:

$ alias

To add an alias to your blink_test program use:

alias blink_test='sudo blink_test'

To permanently add this alias edit your .bashrc or .bash_profile - if you use the bash shell - in your home directory and add that line at the end.

Remember to close and open the shell, open other shell - type 'bash' - or log out and in as .bashrc and .bash_profile are only read on shell start.

There are other approaches as to set /dev/mem group to a group you are in that are somewhat more complex, but used a lot in Linux environments. The wheel group as example can do many admin tasks historically in Linux/Unix and just adding yourself to your group let you read and write many files owned by group wheel that are otherwise unreadable/unwritable.

You can read more abut that here https://wiki.archlinux.org/index.php/Users_and_Groups but don't hesitate to ask if you need more information regarding this.

Hope this helps.