I wrote a simple script to automate creating a symbolic link.
#!/pseudo
today = "/tmp/" + date("Y-m-d")
exec("ln -sf " + today + " /tmp/today")
Simple enough; get today's date and make a symlink. Ideally run after midnight with -f so it just updates it in-place.
This works just fine! ...for my user.
xkeeper /tmp$ ls -ltr
drwxrwxrwx xkeeper xkeeper 2014-10-21
lrwxrwxrwx xkeeper xkeeper today -> /tmp/2014-10-21/
xkeeper /tmp$ cd today
xkeeper /tmp/today$ cd ..
Notice that it works fine, all the permissions are world-readable, everything looks good.
But if someone else wants to use this link (we'll say, root, but any other user has this problem), something very strange happens:
root /tmp# cd today
bash: cd: today: Permission denied
I am at a complete loss as to why this is. I've also tried creating the links with ln -s -n -f (not that "--no-dereferencing" is very well-explained), but the same issue appears.
Since /tmp usually has the sticky bit set, the access to /tmp/today is denied because of protected_symlinks.
You can disable this protection by setting
sysctl -w fs.protected_symlinks=0
protected_symlinks:
A long-standing class of security issues is the symlink-based
time-of-check-time-of-use race, most commonly seen in world-writable
directories like /tmp. The common method of exploitation of this flaw
is to cross privilege boundaries when following a given symlink (i.e. a
root process follows a symlink belonging to another user). For a likely
incomplete list of hundreds of examples across the years, please see:
http://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=/tmp
When set to "0", symlink following behavior is unrestricted.
When set to "1" symlinks are permitted to be followed only when outside
a sticky world-writable directory, or when the uid of the symlink and
follower match, or when the directory owner matches the symlink's owner.
This protection is based on the restrictions in Openwall and grsecurity.
For further details check this.
I am using linux OS and I have been trying to replicate the file permissions into this state -rwxrw-rw
No matter how I tweaked the settings in the Permissions tab (right click on file >> Properties >> Permissions), I have been playing around with the Access and the Execute, and unfortunately whenever I use the command ls -la in terminal, I am never getting that particular file permission state that I wanted.
Additionally, I am also getting somewhat confused especially where the x factor is applicable whenever i choose Read and Write as the option, but I am unable to get rid of it should I use the same option for the next access.
I can only get either -rw-rw-rw- or -rwxrwxrwx as my result
Any ideas how I can replicate/ reproduce a file permission into this state -rwxrw-rw or should this can only be done via using the terminal only??
Use: chmod 766 yourfile or if you have no permission try: sudo chmod 766 yourfile.
I am using Cygwin and trying to change the group access permission with chmod, e.g.
$ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
$ chmod g= id_rsa
$ ls -l id_rsa
-rwxrwxr-- 1 None 1679 Jun 13 10:16 id_rsa
But this does not work. I can change permission for user and others. Seems that the permission level for group somehow keeps the same as that of user?
I was having a similar problem to you, and I was using the NTFS filesystem, so Keith Thompson's answer didn't solve it for me.
I changed the file's group owner to the Users group:
chown :Users filename
After doing that I was able to change the group permissions to my will using chmod. In my case, since it was an RSA key for OpenSSH, I did:
chmod 700 filename
And it worked. In Cygwin you get two groups by default, the Root group and the Users group. I wanted to add another group, but I wasn't able to do it with the tools I'm used to use on Linux. For that reason I just used the Users group.
Cygwin doesn't like files to be owned by groups that it doesn't know.
Unfortunately, that happens quite often in Cygwin, especially if your PC is in a Windows domain where things keep changing.
I also synchronise my files between two PCs, via an external drive, and the uids/gids are different between the different PCs, so this is a source of problems.
If you do ls -l and see a numeric group id instead of a group name, it means Cygwin doesn't know the gid - i.e. it's not in /etc/group, and Cygwin can't query it from Windows either. You can confirm this by running getent group <gid>, where <gid> is the numeric group id.
To fix it, you can either use chgrp to change the group for all affected files/directories, as described in the accepted answer above, or create an entry for the unknown gid in /etc/group, with any unused group name (e.g. Users2).
After doing this, it may be necessary to close all of your Cygwin windows and then re-open them.
An experiment shows that chmod does work correctly to change group permissions under Cygwin.
The experiment used a file on an NTFS partition. Cygwin implements a POSIX layer on top of Windows, but it still ultimately uses the features of Windows itself, and of the particular filesystem implementation.
On modern versions of Windows, most hard drives are formatted to use NTFS, which provides enough support for chmod. But external USB drives typically use FAT32, which doesn't have the same abilities to represent permissions. The Cygwin layer fakes POSIX semantics as well as it can, but there's only so much it can do.
Try
$ df -T .
If it indicates that you're using a FAT32 filesystem, that's probably the problem. The solution would be to store the file on an NTFS filesystem instead. A file named id_dsa is probably an SSH private key, and it needs to be stored in $HOME/.ssh anyway.
Is your home directory on a FAT32 partition? As I recall, recent versions of Windows ("recent" meaning the last 10 or more years) are able to convert FAT32 filesystems to NTFS.
The remainder of this answer was in response to the original version of the question, which had a typo in the chmod command.
Cygwin uses the GNU Coreutils version of chmod. This,
chmod g=0 fileName
is not the correct syntax. I get:
$ chmod g=0 fileName
chmod: invalid mode: `g=0'
Try `chmod --help' for more information.
(This is on Linux, not Cygwin, but it should be the same.)
To turn off all group permissions, this should work:
$ chmod g= fileName
$ ls -l fileName
-rw----r-- 1 kst kst 0 Jun 13 10:31 fileName
To see the chmod documentation:
$ info coreutils chmod
To see the documentation on symbolic file mode:
$ info coreutils Symbolic
The format of symbolic modes is:
[ugoa...][+-=]PERMS...[,...]
where PERMS is either zero or more letters from the set 'rwxXst', or a
single letter from the set 'ugo'.
Like previous answers, not recognized groups cause such issues. It mostly happens in Windows Domains.
The easiest way to fix it is regenerate your /etc/passwd and /etc/group files (parameter -d is needed for domain users):
mkpasswd -l -d > /etc/passwd
mkgroup -l -d > /etc/group
Close and launch Cygwin again.
This is a very annoying issue for me. In my case user135348's solution worked best. The biggest issue with the chown :Users -R approach is that every time a new file is created, it will be assigned to the unknown gid 1049120. It's very frustrating to keep changing file gid.
I tried mkgroup too, but in my case it didn't work: My gid is 1049120.
Based on the rules explained in Mapping Windows SIDs to POSIX uid/gid values : : 0x100000 offset is used for account from the machine's primary domain.
Trying to remove the same offset from 1049120, you get 544, which is built-in Administrators group's RID.
This account is not a member of the local Administrators group; we use SuRun to grant administrator rights without giving out credentials. In this case, mkgroup failed to generate all the possible gids.
Editing the group file and adding a customized group name seems always to fix the issue easily.
I had this issue when working remotely from the Domain and using cygserver.
Running ls -l showed a numeric group id instead of a group name.
I stopped cygserver, net stop "CYGWIN cygserver, and other Cygwin processes, then ran the ls -l again, and group names were then displayed correctly.
I guess cygserver was holding incomplete domain group information.
After restarting cygserver the system continued to work correctly.
#!/bin/bash
find . |while read obj; do
if [[ -d "$obj" ]]; then
setfacl --set "user::rwx,group::r-x,other::r-x" "${obj}"
elif [[ -f "$obj" ]]; then
setfacl --set "user::rw-,group::r--,other::r--" "${obj}"
fi
done
You must specify the group name on the Windows system which your user belongs to.
So I just did this:
chown -R ONEX:Users ~/*
You can find your user name and group here:
A command I executed in cygwin hosed up a bunch of files. Now I cannot delete them. Omitting most of the 'ls' output, here is what I'm dealing with:
% ls -l
ls: cannot access WSERV001.txt: No such file or directory
-rw-r--r-- 1 mccppk mkgroup-l-d 50 Sep 17 16:57 WSERV001.text
??????????? ? ? ? ? ? WSERV001.txt
% rm WSERV001.txt
rm: cannot remove `WSERV001.txt': No such file or directory
% touch WSERV001.txt
touch: cannot touch `WSERV001.txt': Permission denied
The .text file is normal. The .txt file (directory entry anyway) is obviously hosed. Any ideas on how to get the .txt file deleted?
I had the same problem and fixed it as follow (under Win7):
Open a cmd windows (run as Administrator)
takeown /r /f DRIVE:\PATH
icacls DRIVE:\PATH /grant USERNAME:F /T
where USERNAME is your win7 username under which you are running this.
Also make sure cron.exe is NOT running for user USERNAME or SYSTEM (can be checked from the TaskManager) and that no programs from cygwin are running.
Once all has been checked and done, you should be able to delete your files.
Hope this helps,
Jean
I have a reproducible case and none of what is suggested here helps because of permissions restrictions.
Under sygwin:
[Sakis#t0000000000]$ ll
total 0
drwxr-x--- 1 ???????? ???????? 0 Jul 4 02:51 t0000000000_1.db/
[Sakis#t0000000000]$
Trying to take the owner from an admin cmd console:
c:\t000000000
0>takeown /r /f t0000000000_1.db
ERROR: Access is denied.
Trying to delete from an admin cmd console:
c:\t000000000
0>rmdir /S t0000000000_1.db
t0000000000_1.db, Are you sure (Y/N)? Y
Access is denied.
Cannot also change the owner from the windows GUI. It complains that you should have read permissions.
--- RESOLVED ---
Finally, I have managed to delete it by entering a cmd command with administration privileges and execute:
rm -r <dir>
TIP: You have to make sure that the directory in not used at all. You can use the procmon to find you who locks that directory.
Attempts to use chown and chmod, even as root, failed (I don't recall the error).
I'm pretty sure my disk is fine. I run DiskCheckup daily for a strong history of SMART settings, and checked it this morning. No worries there.
Since the original problem and post, I got busy, and just now got back to that same local shell window. Those files were gone. This was a local cygwin shell on my laptop, so I know that no one else "helped". Strange. Those .txt files were just not there anymore.
I'm still curious what would cause ls to output all question-marks like that for all of the file metadata, except for the filename. But the main issue is resolved.
As admin, this should fix:
chown <yourusername> WSERV001.txt
chmod 666 WSERV001.txt
rm -f WSERV001.txt
If not, you might have disk errors.
I am running apache with mod mono and my asp.net app is using mono sqlite as its db. When i refresh the page twice i get the DB is locked error. The folder it is in is chmod 777. The webapp is creating sqlite.db and sqlite.db-journal but it doesnt seem to be able to delete the journal. Also it has problems when i load the page once. It definitely seems to be a permission problem.
i'm confused. What permissions do i need to set these? i tried precreating the files using 777 and had no luck.
-edit- I didnt find a solution however i thought how silly i was being since i was planning to use mysql for my webapp. So i just ported the code and i no longer had issues.
When creating/deleting a file the directory permission matter.
So, if you really want that, you have to set the containing directory's permissions to 777.
Sample:
$ ls -la
total 21
dr-xr-xr-x 2 me me 1024 May 22 19:19 . #no write permissions to directory
drwxrwxrwt 21 root root 19456 May 22 19:19 ..
-rwxrwxrwx 1 me me 0 May 22 19:19 abc #all permissions to file abc
$ rm abc
rm: cannot remove `abc': Permission denied #abc has 777, but deleting doesn't work
$ chmod 777 . #change directoy's permissions
$ rm abc #now removing works
$ ls #file abc is gone
The reason is that when you delete a file, you actually modify the directory and not the file itself.
Think of a hard link: The file itself will not change when you delete one hardlink to it, but the directory changes.
Sounds more like one instance of the session in apache is blocking the other session, i.e. has the db file open exclusively. Try to let the database(model) run as a singleton (or similar) which all sessions access.