How to set the right folder permission to make a program accessible to all users?

Question

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.

But the folder permissions for folders in /usr/local/bin/ are drwxr-xr-x, which I find out is 755. 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.

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.

I re-verify if /usr/local/programs is indeed 775, and it is. Now although I reason that I can copy X into programs using sudo and then use a command to convert all files in programs to 775, I'm getting the feeling there's something wrong with this entire process.

So how do I install X and make it accessible for all users? The reason I'm trying to do it this way is because once I place it in /usr/local/programs/, I'll be creating a script like the one below to make it accessible via the applications menu.

The script:

To create the script:
sudo -H gedit /usr/share/applications/X.desktop

In the file, paste the following:

[Desktop Entry]
Version=1.0
Name=X
Comment=Program X
GenericName=IDE
Keywords=SomeProgram, X
Exec=/usr/local/programs/X/xyz %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=/usr/local/programs/X/icons/icon.xpm
Categories=GNOME;GTK;
StartupNotify=true

Answer 1

/usr/local/bin is the correct directory to put your program so just:

sudo cp ~/X/xyz /usr/local/bin

and do not move it because moving it moves the permissions as well, whereas copying it will give your program the default permissions of /usr/local/bin.

Also, /usr/local/bin is already in the path and if you put the icon in /usr/share/pixmaps, your desktop file becomes:

[Desktop Entry]
Version=1.0
Name=xyz
Comment=Program xyz
GenericName=IDE
Keywords=SomeProgram, xyz
Exec=xyz %u
Terminal=false
X-MultipleArgs=false
Type=Application
Icon=icon.xpm
Categories=GNOME;GTK;Development;IDE
StartupNotify=true

for a program xyz in your home directory in the path X with icon file icon.xpm.

For the official category list have a look here

Answer 2

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.

Yes, /usr/local is an appropriate place for the system administrator to install programs that will be available to all users on the machine.

But /usr/local is usually split into subdirectories bin, lib, 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 bin, lib, share, etc. subdirectories. Perhaps that's closer to what you're describing.

But the folder permissions for folders in /usr/local/bin/ are 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:

1. First, look at whether your Linux distribution ships a package for that software. If that's the case, then use its package manager (apt-get, yum, 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.

2. If you're downloading this software from a website, check if they provide it in a binary package (.deb or .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.

3. 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.

4. 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 INSTALL or 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.

5. 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 $PATH (/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!