Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Currently I have a basic Ubuntu server running a website. The website is for a few students learning HTML/PHP and each student has their own account with a symbolic link to the shared website folder. Since the students are working on the website together, each user needs to be able to modify all the files (index.html for example). So I created a Webdev group containing all of the students with the default umask of 0002 set in their .bashrc (This allows newly created files to be 774). The shared folder is owned by the group Webdev with a chmod g+s so that new files/folders also belong to the group Webdev.

The problem is that the students are using an IDE (Coda 2) and when they create a new file or folder using the IDE the file has the permissions of 644 on the server (not group writable). However when I make a new file through connecting with Cyberduck (SFTP client) the file permissions are 664 (as they should be). So I don't understand why Coda would be any different.

However, after some trial and error I believe that Coda is first creating the file on local disk and then uploading that file to the server. On a mac by default a newly created file is 644. When the client uploads a file that's already 644 it stays 644 on the server side (umask is kind of useless in this situation). I've also tried creating ACL permissions for that folder but an uploaded file from my mac via SCP doesn't get the default ACL permissions.

In Coda there is an option to change file permissions on a transfer. However this option seems to apply a chmod to all files being uploaded or saved. When one of students is modifying a file created by someone else when they try to upload the file or save it Coda tries to also do a chmod but fails because that user isn't the owner of the file.

My current solution is using bindfs... I mount the shared web folder and bindfs sets permissions and group ownership of newly created files. However, bindfs seems to be a bit slow and I'm sure there is a better solution.

Even if the students ditched Coda 2 and used Mac vim with scp the newly created files on the server would behave the same (644) which is default on the mac.

Other options...

1) Either I teach the students to use (ssh/chmod) with their IDE to change their own file permissions when uploading.

2) I make all the students' Macs have the default umask of 0002 which would upload files with the right permissions.

3) Write a corn script to fix the file permissions every 5 to 15 minutes... (This option I think is the worst if students are working together at the same time).

Is there any way that I could make all files that are uploaded via SCP have the default file permissions of 664 even though the uploaded file has a lower permission? (After hours of searching I don't think this is possible) I guess a corn script is my best option for novice users. How do web developers work together on larger sites?

similar to this: http://serverfault.com/questions/283492/how-to-specify-file-permission-when-putting-a-file-using-openssh-sftp-command

Also similar: http://serverfault.com/questions/395418/managing-linux-directory-permissions-sftp

share|improve this question
add comment

3 Answers 3

Coda actually uploads local files. Unless you use hacks like the now unsupported/outdated http://sftpfilecontrol.sourceforge.net, the files will have whatever permissions they have locally. Since OSX has umask 022, files created on OSX are not group writable, so 644. Coda happily uploads that. As you found out, Coda can force specific permissions, but it isn't fine grained enough to specify it should only be done for new files, so it will error on saving existing files that aren't owned by the user (which is the most common case). The only way I got this to work, is by changing the users umask on OSX. Create the file /etc/launchd-user.conf and put in there:

umask 002

Then reboot. Afterwards, Coda creates files that are 664 locally, and uploads them. Files are now properly group writeable, and there is no need for the Set permissions on upload option in the Coda prefs.

See also http://support.apple.com/kb/HT2202.

share|improve this answer
add comment

In the Coda preferences panel, under the Rules tab, it looks like you can set the desired permissions for files uploaded via ftp/sftp. The default is 644; looks like just checking the "Write" box in the "Group" line could fix the problem. Each student would have to do this in their own copy of Coda, of course.

share|improve this answer
    
I talked about this in my post... Coda seems to apply a chmod to all files that are saved/uploaded. If the student is modifying a file that he/she doesn't own Coda returns a big fat error. The exact error is "Make sure you have permission to modify this file. This server or file may not allow you to adjust permissions. Double-check that your permissions in the Rules preferences are set correctly." –  Tom Black Jun 14 '12 at 21:33
add comment

The problem is not the permissions on the file, but the group(s) to which your students belong. On the web server machine, if you make each student's primary group the same as web-server's group (on Linux systems usually www-data or apache), and set the Default File permissions to 660 in the Coda prefs pane, all should be well.

# usermod -g apache studentUID

or

# usermod -g www-data studentUID

depending upon which flavor of Linux you're running on the web server.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.