I have a permissions question that I’m sure has a simple answer but one I can’t find. When saving files through SSH using kate or kwrite, the permissions always reset to 644 when I want them to stay at 666/777. When using notepad (not sure what this is, it’s just in my right click contex menu under “open with…”) the permissions persisted after I saved. Permissions also persist with kate and kwrite on my local machine.
Is this something I need to configure on the server?
Using Opensuse 11.2, kde 4.3, kwrite 4.3.1-5.6.3, kate 4.3.1-3.7
I’m not 100% sure, but it sounds to me that you want to change the umask value. You can read about this with
man umask
I think what you want is to add the following line to your .bashrc file
umask 000
The default is 022, which would give permissions for a new file created by ssh to be 644 (666 - 022). I don’t think umask has an effect on files that have already had their permissions modified. Only new files.
Ok I put “umask 000” in my .bashrc (remote .bashrc right?) and tried creating a new file and saving old files through kate. Both times the file got 644 permissions.
umask can only take away permissions. If the application does not specify the relevant write permission when creating, there is no way umask can force it to be turned on.
Why do you want allow group or other write on your files? Perhaps if you explain what it is you want to do there may be a better way to get to the goal.
I read that umask only restricted permissions and noticed the difference when creating new file with vim, so I don’t believe this is what I need.
I’m working on a web project with a couple other people and we have all the files in the project set to 666 so that we can all edit them. Every time I edit a file with kate or kwrite it changes the permissions to 644. This is annoying when we’re debugging javascript because I make a ton of small changes quickly. I just want existing permissions to persist on a file after saving it.
I removed umask 000 because 644 is a good setting for file creation.
The traditional Unix permissions are not sufficient to enforce turning on particular permission bits. For this you need the POSIX ACLs. The two man pages to read are getfacl and setfacl. They are not easy to read, I’m afraid, so try to search for a tute maybe.
What you need to do is set the default ACL on the top level to allow group write and this will propagate down and affect new files created underneath. Existing files may need to be have their ACL set using the recursive option of setfacl. However there are some caveats, as this post shows that files copied into this tree may not have the write permission. But if you are creating within the tree, it should work.
Kate/kwrite are running on my local. Originally I navigated to the directory with dolphin and right clicked the file -> open with -> kate or just drag the file into kate. Now all the files are saved as a session in kate.
I looked into the ACL (it’s a BSD system) and it just seems like a little bit over kill. I just want kate/kwrite to maintain the same permissions coming out that they got coming in. Notepad was running under wine but did this.
Interesting. So you’re “mounting” ssh from a Unix box with fuse … or something like that. It that case I guess it’s a nontty session and your ~/.bashrc on the server side is ignored.
Actually, on further investigation, I believe it sftp’s the file over (it will ask me for credentials if I’ve been idle for awhile). I’m guessing it saves a copy locally on my machine which has the wrong permissions before sftp’ing it to the server. Maybe I can write a plugin/extension for kate that will grab the file’s permissions for when the local version is created? Any clue where I could look for where the local versions might be stored?
You should also create a group for users involved in this project and rather use the permission 664 on all files. So they will be writable by the members of the group an not by others.
I found the temp files under .kde4 in my home directory (local) and they have permissions of 600 so somewhere along the chain they are getting changed…