I have a program X which I want all users of my computer to be able to access. So I can't put it in my home folder. So I hear that
/usr/local is the right place and tried that.
/usr/local is an appropriate place for the system administrator to install programs that will be available to all users on the machine.
/usr/local is usually split into subdirectories
share and the expectation is that you'll install your program into those subdirectories, for example a
/usr/local/bin/X binary, a
/usr/local/lib/libX.so.1 library, perhaps some additional data directories under
share and so on.
Typically Linux programs that you build are able to install into
/usr/local with the
make install command, more exactly
sudo make install since only root can write to those subdirectories. (At least, that's a fairly common convention for software built from source.)
There's also the
/opt hierarchy, which is expected to hold each program in its owni subdirectories, so
/opt/X-1.0/ and that directory would have its own
share, etc. subdirectories. Perhaps that's closer to what you're describing.
But the folder permissions for folders in
drwxr-xr-x, which I find out is 755.
The permissions are correct.
The issue you're having have nothing to do with the permissions really, but with the fact that only root is able to write to
/usr/local, and that's how it's meant to be.
See my point above about installing programs from source using
sudo make install (assuming you're building from source and the source uses a Makefile that supports that), in short you should use
sudo to have root create those files, with root ownership, as it was intended.
So I create a folder named programs using sudo mkdir programs and change it's permission using sudo chmod 775 programs, because the folders in the home folder have the permission 775, and I figured that'd be the right permission to give it.
Don't do that.
/usr/local is not really meant to be used that way. (It doesn't mean people won't abuse it in similar ways, but you might as well learn to use it correctly or to find a more appropriate place.)
Now I go to cd
/usr/local/programs/ and try to copy program X from the home folder to the programs folder using
mv ~/X/ . and I get an error that
mv: cannot move '/home/nav/X/' to './X': Permission denied.
So the problem is that you need root. Using
sudo would help, but the files under
X/ would still be owned by your user. (That would not necessarily prevent them from being used by other users in the system, but typically you want these files under
/usr/local to be owned by root.)
There's no problem with permissions, and 0755 is typically correct for root. All you need is to have the "other" read and execute bit, so users will be able to run those binaries.
As mentioned, if you want to keep a program in its own subdirectory, then perhaps
/opt is a more appropriate place. Though even in that case, you typically want root ownership for the files. Also
/opt is becoming less and less popular, it's probably a quite unusual choice these days...
How to do this right
Unfortunately, installing software on Linux correctly depends a lot on which software you're installing. And the way to install it usually depends on how it's built and also to some extent which programming language it uses.
I'd recommend the following:
First, look at whether your Linux distribution ships a package for that software. If that's the case, then use its package manager (
dnf, etc.) to install the package. If the main repositories don't have the package, check whether there are extension repositories you can enable to get the package from.
If you're downloading this software from a website, check if they provide it in a binary package (
.rpm, etc.) for your distribution, rather than a tarball (
.tar) with binaries.
Installing a package should always be preferred, since that's made to properly integrate into your system. Packages coming from your Linux distribution (assuming they're available and the version shipped by the distribution is acceptable to you) have an even better chance to working fine on your system.
If you're building it from source, then try to install it to
/usr/local. That's often the default, particularly for packages using autoconf/automake. If there's a
./configure.sh script to run at the start of the build, you can typically pass it a
--prefix argument to customize that (as in:
./configure.sh --prefix=/usr/local). After building the software, use
sudo to install it:
sudo make install.
If the software is using a different build system and/or programming language, see if you can find equivalent instructions to accomplish the same. Source packages usually ship files named
README in all caps at the top of the source tree with instructions on how to build/install them and get started with them. Read those.
Unfortunately there's a lot of variation there. There are a few standards but actually too many of them and building/installing software on Linux/Unix often involves some trial and error, deciphering confusing error messages and finding and reading instructions trying to figure out whether they'll do what you expect them to... Once you start doing that often, it gets a little easier, but there's always quirks you need to look into.
That's why using packages from a distribution is so much better, at least you have a standard there, you have a standard set of tools you can use to install and manage them and the build details have all been taken care of for you.
- If you're getting a binary tarball from a website, then by all means look at their instructions of how to unpack and use that tarball. You can possibly guess, but you're likely to make mistakes or, at the very least, not keep it as tidy as it should be. Consider unpacking the tarball directly as root (using
sudo). If the tarball ships a subdirectory named after the program, consider using
/opt as a base directory. Consider creating symlinks somewhere in your
/usr/local/bin comes to mind,
/opt/bin is good but only if it's in your
$PATH already) for the binaries that are expected to be called by users from the command line.
Unpacking a set of pre-built binaries is typically the hardest one to get right. If that's what you have, look for instructions on how to unpack that correctly.
Hopefully this information will be useful in deciding how to manage the specific package that you have!