Gulp-sass: Error: EPERM: operation not permitted, chmod

[Albert221]

const gulp = require('gulp');
const sass = require('gulp-sass');
const csso = require('gulp-csso');
const autoprefixer = require('gulp-autoprefixer');
const uglify = require('gulp-uglify');
const addsrc = require('gulp-add-src');
const concat = require('gulp-concat');
const imageResize = require('gulp-image-resize');

const targetDir = 'dist';

gulp.task('default', ['sass', 'js', 'thumbnails']);

gulp.task('sass', () => {
    return gulp.src('src/scss/**/*.scss')
        .pipe(sass().on('error', sass.logError))
        .pipe(addsrc('src/css/**/*.css'))
        .pipe(autoprefixer())
        .pipe(csso())
        .pipe(concat('style.css'))
        .pipe(gulp.dest(targetDir))
});

// (...)

What's wrong that gulp sass doesn't have permissions to write to dist/style.css when current user is in group that is owner of this file?

[xzyfer]

We don't to anything with permissions. Check that your gulp process has permissions to write to your diet directory. There's nothing we can do here.

[lustosa]

It seem to be a bug. Apparently, gulp really does something with permissions, hence the error while trying to 'chmod' the file.
His screenshot shows he is in the group (https), and the file has group write permissions.
I get a similar error here too. It writes the files, but fails to chmod it. Why it's trying to chmod the file, I really don't know.

[nicoHersant]

Hello everyone.
Got the same issues today:

"Error: EPERM: operation not permitted, chmod '/.../vendor/bootstrap/css'"

.
I don't have much time to look at it so i used the barbarian way : log as root to execute the "gulp" command.
But this is strange, even if you gave the permission on the folders and files, gulp as current user still try to use chmod...
Have a nice day.

[ahmedelbougha]

Actually, it's a Linux issue not a gulp issue. The problem is that only the owner of a file or root users can change the permissions of of a file, but group users are not allowed to do so.
The solution that I did to fix this problem is to change the owner of the file in following way:
chown myuser:http . -R
Of course with keeping permissions as 775 or 755.
This way Apache user (as group user) is still allowed to run/read the files and my user is allowed to run glup command with tasks including chmod.

[dankolz]

I see why it's happening. But why is the chmod being done at all? I'm seeing a similar problem and my permissions on that file are 777.

[jorismak]

@ahmedelbougha the issue is not that linux prevents a chmod for not-owners..

the issue is why is chmod being attempted :). It shouldn't touch permissions.

[lustosa]

@jorismak exactly. gulp shouldn't be attempting to chmod anything, it's not its purpose.
As a very dirty workaround, I've been using the code below for the past few years. Just put it somewhere in the gulpfile, and it should bypass the actual chmod call:

const fs = require('fs')

if (1) {
fs.chmod = (a, b, cb) => cb(0)
}

[dankolz]

@xzyfer Is this a behavior change you'd accept a patch for? It inconveniences me and my clients enough that I'm willing to put a couple hours into it. Seems like it would be usable by others as well.

[jorismak]

For what it's worth.

My situation is that we have a staging server where each dev has his own username. So the first one to build is the owner. The group and ACL permissions are set just fine, so everyone can write / modify / etc... but not chmod, because that's only for the owner. So a second dev can't run the release script without gulp errors because a file in the output folder is not owned by him.

Our solution is simply to clean the output folder before running gulp. Then there are new files created owned by the 2nd dev. Since the ACLs are set fine he has enough permission to delete the file and recreate it (but not chmod it 🤯 ).

This is a legacy project so the dependencies used are probably outdated, so I have no idea how the 'modern' situation is.

We also hardly run into this issue since most projects are deployed through CI/CD, or always by the same user. This was the first in a long time when two people were involved enough in a (legacy) project to attempt a release :).