Just curious what would be a good workflow or rules of thumb for working with the files via IDE and the CMS interface. Seems like when I add myself as an owner (OS X) it still gives me an error when trying to save a file. What's the best way of dealing with permissions and ownership while developing locally?

I'm facing the same problem. Every page, content, layout written to disk, set the owner:group as "apache:apache" with permissions set to "644", using my code editor, I can't edit even when my user is under the "apache" group. Currently, I have to change permissions every time the CMS write to disk.

We have a solution for this in mind, when a file is modified/created by the web server, it will chmod() the file to be writable (777). There is a configuration value for this already in the file /app/config/cms.php

    /*
    |--------------------------------------------------------------------------
    | Default permission mask
    |--------------------------------------------------------------------------
    |
    | Specifies a default file and folder permission for newly created objects.
    |
    */

    'defaultMask' => ['file' => null, 'folder' => null],

Should be implemented soon.

Last updated 10 years ago

That's alright, but if you take the files down to your local IDE and then push them back up via FTP, you end up with 644 being re-set and not changed. I would suggest a chmod set prior to the attempt to save a file because it fails silently, which is going to be very confusing for people just handling page content and have no idea that their changes haven't been saved because of file permissions, which they'll likely have no concept of.

Has this been implemented yet?

i fell in the exact situation fred.bliss495 mentioned..

i spent an evening working in the backend on layouts and partials.. and just discovered nothing have been saved because of 644 permissions.. but i got no warnings or anything else...

Has there been an update on this?

777 seems like a temporary fix, fine for your laptop, but not something you should leave as such, and not something you should be doing in a shared hosting environment.

I'm going in as root to recursively set owner back to myself, and the group to www-data ( or www in my case ) , with 775 permissions, and I'll see how that works going forward. Alt would be to create a new group for my login, and switch it up so www-data is the owner and my login is the group so as new files are created the group is inherited.

Hi under linux what I've made is enable the setfacl on the root application folder.

setfacl -R d:u:YOURUSERLOGIN:wrx,d:g:www-data:wrx,d:o:--- YOURROOTPATH/

the d before attributs make this a default rule, so even a plugin made by the Build plugin(under the cms backend so by the webserver service), files created are owned by the user so you could edit without problem. But for sure only some folders must have the write rule too, but for my dev .env I take all ok for my apache

Last updated 8 years ago

Interesting solution.

Under FreeBSD I ended up creating another group, with my login added to it. I then owned all the files to WWW user and the group I created.

I can now edit it via the shell and not have anything break in the hosted GUI page, and don't have to set permissions to 777.

I usually create a web group and add all the users allowed to maintain the website to it (myself included). What I do next is I chown the whole October CMS folder recursively to www-data:web and then chmod -R it to 570 - this gives read and execute access to apache, full access to developers and denies access to everyone else. Then, I selectively do a chmod u+w to files and folders which the CMS needs to write to.

Thus, I set the file and folder masks in config/cms.php to 770 which allows the CMS (and the developers) to read and write to files that it creates. I also set the group bit on the whole application directory so that every new file created within the directory inherits the web group (chmod g+s).

I have found that this kind of setup works pretty well when you want to give full access to developers and allow the CMS to write to disk.

Last updated 8 years ago