Unless you've done something unusual with your device, the SD card will be formatted as a FAT file system, which does not support *nix file permissions. This Linux FAQ entry from one of MIT's professors explains it a bit, and also explains how you can potentially use mount options to change the permission mode of the device (this would require root, though, ...
One of the restrictions introduced with 4.4-kitkat was moving the WRITE_EXTERNAL_STORAGE permission to protection-level "SignatureOrSystem", which means even if requested, a "normal app" (i.e. one you install yourself as "normal user" without any root specialities) will no longer get it granted. So there are very few things you can do to "work around" this:
This is due to 2 things:
The file does not have execute permissions [AND]
The file cannot gain executable permissions as it is on the SD Card. The SD Card's filesystem can accept file permissions, however it is mounted with the noexec flag, as stated in a comment. This stops files being executed.
Copy the net-snmp-5.7.2 directory to the /data/...
As explained by the comments and Liam's answer, this is due to the noexec flag used by the system when mounting the sdcard. If your configure file is a shell script (as it usually is), you can still trick it to be executed:
cd to the directory as you described above, and then execute sh configure.
sh is the Shell interpreter, and that binary should be ...
It's difficult to tell for certain without a bit more context, but it sounds like the instructions are attempting to convey the Unix filesystem permissions to set on the database.
Since Android at its core runs on the Linux kernel, its filesystem maintains the same permission and access rules as any typical Unix system does. In general, there are three ...
There's nothing magical to restore /system partition to original state. Many users gain root access temporarily to remove bloatwares from /system/apps & then unroot.
But, remember, if un-rooting method involves flashing /system image, you'll lose your changes. So, use proper un-rooting method.
As eldarerathis already mentioned: On many (if not most) devices supporting an SD card, this card is mounted with the noexec option -- which means as the name suggests: "no exec from here", i.e. you cannot execute anything from the sdcard.
Again, one solution was already mentioned by eldarerathis: Try a different storage. You've got the power, your device ...
First, make sure adbd is running as root:
If you get an error that says something like "unable to run as root on production builds" it means that you must always issue su command in the adb shell to gain superuser privileges. You will need to enter the shell before any mount commands will work. You will need to push the file to the SD Card, then ...
Edit: I found a work-around: AirDroid allows me to upload the file, but the permissions on the file are set to this:
Performing the following commands solves this problem (from Windows 7 command prompt).
# chmod 777 /data/data/com.me.app/databases/data.db
Yes, this is by design. You can't execute binaries from the SD card without system or superuser privileges (and remounting it without the noexec option) because otherwise apps could just download and execute malicious code at will. In older versions of Android the SD card also did not have emulated permissions so chmod would naturally fail.
Android, just as Linux, prevents any user but root, to change the permission bits of any file not owned by such user. That said, chmod is ineffective, unless you have root privileges.
By the way, even if you had such privileges, you wouldn't have been able to change permissions, as long as the target path is /storage/sdcard0 or /storage/emulated/0. This ...
Newer versions of Android require apps to ask for permission during runtime. You may have noticed this already. One example is Chrome asking for the Storage permission when you try to download something for the first time. For Termux, this is a problem. Permissions default to "not allowed," so when Termux needs a permission for a task, because Termux hasn't ...
A few things that will do you good before you start resolving this issue.
This issue has been around since CM 9 and has been inherited by CM 10.
While ROM Manager (and not CWM) was the culprit some time ago, the issue has since been resolved by them.
The .nomedia file you are looking for should be inside /sdcard/Android/data. It may not be there but can't ...
Chmod will never be supported. That's on purpose according to comments in the source code.
Here's a reference to the FUSE implementation on Github pointing to a comment that says this.
And the original head on Googlesource (a bit harder to navigate than Github).
Even root cannot bypass it:
shell@android: # id
Make a backup of your data first.
every folder and file in the /sdcard/data directory is 0 bytes.
This looks like a corrupted filesystem or a defective sdcard (see correction). Especially, folders have a usual minimum size of 4.0K.
I'd suggest you to back up your data first, then check for errors:
Does "dmesg" show filesystem errors on mmcblk0 or ...
Use these commands
su -c 'busybox mount -o remount,rw /' # this will remount rootfs at / in rw mode
su -c 'mkdir /mnt/"NEW_DIR"' # replace NEW_DIR with the name of the directory you aim to create under /mnt
Note that in Android /mnt is not a mount point for any real or pseudo-filesystem but its sub-directories are (actually, /mnt is a sub-...
When you use your phone, access applications and navigate it's file system, you do so as a user with a given set of permissions. This places certain restrictions on what you can and can't do or access.
Rooting your phone places an executable on your device called su (switch user), this executable switches the account credentials and permissions that you ...
On all operating systems based on Linux kernel - like Android is - it's possible to set permissions on files (including directories) provided that filesystem supports UNIX permissions (uid, gid, mode). Common examples of such filesystems are ext4 and f2fs.
However Android's internal (confusingly called external) storage which is accessible by installed apps ...
You may need to remount your file system to enable write. I'm not sure how that's done with Root Explorer, but from the Terminal it looks something like:
mount -o rw,remount /partition/name/
You can get the partition name by typing mount without any parameters.
As a final resort, I tried doing a full wipe and reinstalling CM10 M1 completely, without restoring any settings or apps from any old installations. The issue still persists! Any files created with my now "old" CM10 installation no longer appear, even when they are moved within a folder where other "new" files are shown and working. Switching back to AOKP ...
Yes, your phone must be rooted because to access that file the /system needs to be mounted as write-able
Once you obtain root you can run this command inside a shell:
chmod 777 /sys/class/leds/button-backlight/max_brightness
Then just navigate to that file and edit it using a file browser. What the chmod 777 command does is change the permissions on ...
Based on Linux, Android supports the addgroup and adduser commands (I just checked on one of my devices, and the command exists). I'm not sure whether it supports the full set of options available on Linux, but what should work is at least
# create a new group
addgroup [--gid ID] group
# add a user (app) to that group
adduser <user> <group>
For setting file permissions, you can use the chmod command. The permissions shown are basically split in 3 parts, each consisting of 3 chars: a triple for the owner, the group, and for "others". Usually, each triple holds definitions for reading, writing, and executing a file; so rwx means "can read, write, and execute", while r-- would say "can only read".
You probably need to root it to gain access to the protected "/system" file system.
XDA Developer's has a (probably) outdated thread how to do it here.
After you suceeded, you can take the usual steps to mod it (remount /system read-write, copy your edited file over, etc.)
Most recoveries don't work in root mode - and root mode cannot be acheived, as the SU binary calls your superuser app to gain permission to use root mode.
As the su binary cannot call the app, it stops you using SU mode.
It could also be due to the fact that the su file used in recovery is the stock su file found in Android, and this doesn't let you switch ...