Istvan Gabor wrote:
If the startup script is creating them then udev is out of the picture as long as udev has run before bestcrypt. The permissions/ owner must be set in the bestcrypt startup script. No need to create any udev rule if the startup script is creating the device entries.
Mark
Thanks. But see the bcrypt start script:
[snip] MAJOR=188 MINOR=0
case "$1" in start) echo "Initializing BestCrypt." rm -rf /dev/bcrypt?* 2>/dev/null for (( x=0 ; x<16 ; x++)) ; mknod -m 666 /dev/bcrypt$x b $MAJOR $(( MINOR+x )) ; done [snip}
According to this the permissions should be 666, not 644 as they are. How can I get then the right permissions?
Are you are saying that after you boot the machine and start the service manually, (/etc/init.d/bestcrypt start) the permissions are wrong? I suspect they are correct and it only happens incorrectly when you boot the machine and let the service start normally. If that is the case then the service probably needs to start later. When does the bestcrypt service script start? If the permissions are not 666 after manually starting the script, what happens when you really do it manually? Try one of the 16 and see: rm /dev/bcrypt0 mknod -m 666 /dev/bcrypt0 b 188 0 ls -al dev/bcrypt0 Or, is the startup script maybe changing the mode later after creating them? Mark