February 23, 201313 yr So I was installing sabnzbd on my tower (Without the use of a tutorial, because, I prefer to learn than follow instructions) and I set it all up/etc, however, whenever I launched up a download it'd instantly be sent to the "STATUS" page as if it wasn't part of sabnzbd (and just an extra folder), then, if I tried to hit "add" it'd throw something about "No permission to read _ADMIN_". Anyway, so, after around an hour of googling I gave in and read the tutorial, I worked out my mistake was that under folders I had set "Permissions for completed downloads" to be 666 instead of 777, and, I did this because so this page says:- http://answers.yahoo.com/question/index?qid=20080917060335AA2xL3E 1 means execute (So read (2) and write (4) would be 6, am I right?), and, I don't see why they have to execute (Because they're just being read by sabnzbd). Anyway, I changed it to 777 and now it works fine, can someone tell me why it didn't work before though?
February 23, 201313 yr But the X permission bit does not mean that for folders. (You cannot execute a folder.) Instead that bit says whether or not the folder is hidden/searchable. That's why you need the bit set. As another example, if you set permissions on a folder within a share to 666 you cannot browse the contents of that folder remotely. If you set them to 777 then you can.
February 23, 201313 yr Author But the X permission bit does not mean that for folders. (You cannot execute a folder.) Instead that bit says whether or not the folder is hidden/searchable. That's why you need the bit set. As another example, if you set permissions on a folder within a share to 666 you cannot browse the contents of that folder remotely. If you set them to 777 then you can. Fair enough, but, if I did something like:- CHMOD -R 777 /blah Would that set all folders to visible and all files to executable, or, what?
February 23, 201313 yr Yes, it would. If you don't want the execute permission on files, though you could do something like this... chmod -R 777 * chmod 666 $(find . ! -type d) This will change all files and folders from the current level downwards to 777. The second command then applies 666 permission to all files found but does not modify folders folders. Just be careful to ensure you are in the correct directory before running these (use pwd to check). There are very many ways you can address this problem. Some googling around on managing Linux permissions will provide many alternative approaches.
February 23, 201313 yr If you are using unRAID 5.0 rc11 then you could also use the 'newperms' command that will set folders to have execute permissions and files to not have that permission.
February 23, 201313 yr If you are using unRAID 5.0 rc11 then you could also use the 'newperms' command that will set folders to have execute permissions and files to not have that permission. ... which can be a problem with plug-ins and the like on the cache drive (if used) since the executables are then marked as not. Hence the need to sometimes do things the hard way.
February 23, 201313 yr If you are using unRAID 5.0 rc11 then you could also use the 'newperms' command that will set folders to have execute permissions and files to not have that permission. ... which can be a problem with plug-ins and the like on the cache drive (if used) since the executables are then marked as not. Hence the need to sometimes do things the hard way. True - but this is just as good as using simple chmod -R options that have been discussed so far and is easier to use as well as keeping permissions as unRAID expects them to be set up. The thing to do is probably give explicit path as a parameter to the 'newperms' script to keep it away from any areas that have executable files in them, or to have a script that you set up for explicitly settings executable bits on specific files.
February 23, 201313 yr The thing to do is probably give explicit path as a parameter to the 'newperms' script to keep it away from any areas that have executable files in them, or to have a script that you set up for explicitly settings executable bits on specific files. Agreed - that's almost certainly the better approach for most users (self included).
Archived
This topic is now archived and is closed to further replies.