Chmod a Freshly Mounted External Drive to Set Up Writing Access

chmod a freshly mounted external drive to set up writing access

Try this first,

umount /dev/sdb1

chmod -R 0777 /mnt/external   

then mount with

mount /dev/sdb1 /mnt/external

or try

chmod -R 0777 /mnt/external

How do I change permissions for a folder and its subfolders/files?

The other answers are correct, in that chmod -R 755 will set these permissions to all files and subfolders in the tree. But why on earth would you want to? It might make sense for the directories, but why set the execute bit on all the files?

I suspect what you really want to do is set the directories to 755 and either leave the files alone or set them to 644. For this, you can use the find command. For example:

To change all the directories to 755 (drwxr-xr-x):

find /opt/lampp/htdocs -type d -exec chmod 755 {} \;

To change all the files to 644 (-rw-r--r--):

find /opt/lampp/htdocs -type f -exec chmod 644 {} \;

Some splainin': ^{(thanks @tobbez)}

• chmod 755 {} specifies the command that will be executed by find for each directory
• chmod 644 {} specifies the command that will be executed by find for each file
• {} is replaced by the path
• ; the semicolon tells find that this is the end of the command it's supposed to execute
• \; the semicolon is escaped, otherwise it would be interpreted by the shell instead of find

Ubuntu - Jenkins unable to access mounted hard disk

I found a solution for my problem from this. I had to update the access permission for the user to access the mounted drive using the below steps

1.Unmount the mounted device (/dev/sdb is the hard disk detected name)

umount /dev/sdb
chmod -R 0777 /mnt/

2.Finally mount the hard

mount /dev/sdb /mnt

3.Then I gave the sdk path as /mnt/Android/Sdk

Jekyll: Operation not permitted @ apply2files

These "operation not permitted" errors seem to be related to user rights or ownership.

I have seen strange errors on colleagues' MAC computers. The command ls -al showed that certain folders were owned by root.

If this applies to you, try to change/transfer ownership to your user with these commands:

• sudo chmod -R 777 /mnt/e/Work/project/
• sudo chown -R youruser /mnt/e/Work/project/

The difference between chmod and chown is simple:

• chmod changes modes
• chown changes ownership

Note: This is explained in detail on unixtutorial.org.

For the Windows Linux Subsystem, I have found this old blogpost devblogs.microsoft.com from January 2018:

How did permissions work in the past?

Prior to Build 17063, all files/folders list “root” as the owner and belonged to the group “root”. The permission bits on each file/folder was derived from Windows permissions–no write bit checked for Windows meant no write bit set in WSL.

Additionally, attempting to chmod or chown on a file/folder resulted in a no-op (they wouldn’t do anything!)

How do permissions work now?

For files that don’t have metadata, we apply the same approach as what is described in pre-17063 builds. But now, chmod/chown can assign metadata to the file or folder. Newly created files in WSL will be created with metadata by default and will respect the mount options you’ve set (discussed later) or the permissions you pass when executing a mkdir/open.

And, I have found this SO post:
chmod WSL (Bash) doesn't work, which states that it's enough to unmount and re-mount the drive to make chmod and chown work (after the mentioned WSL update).

Getting the warning Insecure world writable dir /home/chance in PATH, mode 040777 for rails and gem

If you tried sudo chmod go-w /usr/local/bin from the other answer, try:

chmod go-w /home/chance

instead.

What seems to have happened is that somehow your home directory (/home/chance) has been added to your $PATH (the list of directories the OS searches when trying to find an executable to launch) and has also had its permissions changed so that anyone can write to it. This is potential a security problem, as another user could put an executable into this directory which you could accidentally launch. Ruby notices this and issues the warning.

This command changes the permissions of the directory so that it is no longer world writable.

In unix, file permissions are specified for three categories, the file owner (user), the group of the file (group), and everyone else (other). (See Google for more on unix file permissions).

So breaking down the command above:

chmod - change the 'mode' of the file (i.e. its permissions)

go - for group(g) and others(o)

-w - (minus w) remove write permission

/home/chance - the file (or directory) in question

In the other answer the directory that was causing the problem was /usr/local/bin, which is owned by root so sudo is required to change permissions on it. /home/chance is your home directory which is owned by the chance user who can change permissions on it - no sudo required.

---

Related Topics