Stlink: [doc] Verify correct udev configuration for device access

How did you install stlink?
If you do the following you should not need sudo to run the commands (so long as it is not run as root):

git clone https://github.com/texane/stlink.git
cd stlink/build
cmake ..
make && sudo make install

Note that you may also need to update your udev rules if you have not already.
stlink_udev_rule.tar.bz2
sudo tar -xvf stlink_udev_rule.tar.bz2 -C /etc/udev/rules.d

Hello and thanks for the quick answer
today I pulled the last git (6a9d390a729f381ecec45f212354bfe98e27790f)
then in build I did
make clean
cmake ..
make && sudo make install

I also copied the udev rules into /etc/udev/rules.d.
I made the udev rule executable and then I restart the whole computer

However when I do
st-flash write main.bin 0x8000000
I got
st-flash 1.4.0-58-g6a9d390
2019-01-24T22:21:17 INFO usb.c: bus 483 dev 3748
2019-01-24T22:21:17 WARN usb.c: Couldn't find matched ST-Link/V2 devices
If on the other hand I do
sudo st-flash write main.bin 0x8000000
It works fine.

Just for information
lsb_release -a && uname -a
get me
No LSB modules are available.
Distributor ID: neon
Description: KDE neon User Edition 5.14
Release: 18.04
Codename: bionic
Linux zalman 4.15.0-43-generic #46-Ubuntu SMP Thu Dec 6 14:45:28 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

Do you have an idea, what I should do?
best regard

It works fine for me under ubuntu 18.04.

To investigate, start by plugging your STLINK device into the usb port. Then run lsusb. You should see an entry something like the following:

Bus 005 Device 017: ID 0483:374b STMicroelectronics ST-LINK/V2.1 (Nucleo-F103RB)

Note the bus number (005) and the Device (017). You should then do:
ls -l /dev/bus/usb/005/017 (replacing 005 and 017 appropriately).

On my system I see the following:

crw-rw-rw- 1 root root 189, 528 Jan 24 17:52 /dev/bus/usb/005/017

which is world writable (this is from the MODE:="0666" below). I have several files in my /etc/udev/rules.d directory. In this particular case, the 49-stlinkv2-1.rules file contains the following:

# stm32 nucleo boards, with onboard st/linkv2-1
# ie, STM32F0, STM32F4.
# STM32VL has st/linkv1, which is quite different

SUBSYSTEMS=="usb", ATTRS{idVendor}=="0483", ATTRS{idProduct}=="374b", \
    MODE:="0666", \
    SYMLINK+="stlinkv2-1_%n"

# If you share your linux system with other users, or just don't like the
# idea of write permission for everybody, you can replace MODE:="0666" with
# OWNER:="yourusername" to create the device owned by you, or with
# GROUP:="somegroupname" and mange access using standard unix groups.

and the idVendor od 0483 and idProduct of 374b matches the vendor id from the lsusb output.

Make sure that you have all 3 files from here: https://github.com/texane/stlink/tree/master/etc/udev/rules.d in your /etc/udev/rules.d directory. After copying new files or editing excisting files in /etc/udev/ruled.d you should run the following:

sudo udevadm control --reload-rules
sudo udevadm trigger

to ensure that the rules actually take effect. Using the trigger command means that you shouldn't need to unplug and replug the device, but you might want to try that for good measure as well.

If the VID:PID of your device doesn't match those in any of the 3 files, then you may need to create a custom rule file to match your VID:PID.

Hello and thanks for you answer
I did all this
ls -l /dev/bus/usb/001/011 crw-rw-rw-+ 1 root root 189, 10 Jan 25 19:56 /dev/bus/usb/001/011
It is still the same.
By adding the command in sudo visudo, i don't have to enter password anymore but still need sudo.
That is weird

@dhylands would you like to update the documentation with the extensive description? At https://github.com/texane/stlink/blob/master/doc/compiling.md#permissions-with-udev.

@dhylands: May I copy-paste your description to our documentation?

@Nightwalker-87 By all means - feel free.

@davehylands: Thank You for your helpful contribution and feedback.

Closing this with commit d3c11fbef6d8205742152f646b223323dc4c0913 as we know by now that the udev configuration is functional.
I can confirm this with a recent debian system as well.

The problem appears to be an isolated issue on a local installation that we can not reproduce.
A concluding advice is to retry with a clean (system) installation with default user permissions.