setfacl error while deploy:writable: Only directories can have default ACLs

[dakur]

• Deployer version: 7.0.2
• Deployment OS: Ubuntu 18

When I try to deploy with 7.0.2, it fails with err setfacl: log/.gitignore: Only directories can have default ACLs. If I downgrade to 7.0.1, it works. It appeared that it's not about version, but about if I deploy for the first time when no dirs exist yet, or when the directory structure already exists. In first case, it fails, in the second it deploys without problem.

I use setfacl permissions on remote machine.

<?php declare(strict_types = 1);

use function Deployer\{after, desc, import, run, task, upload};


require_once 'recipe/common.php';

import(__DIR__ . '/config.yml');


task('deploy:copy', function () {
	upload('..', '{{release_path}}');
});

task('deploy', [
	'deploy:info',
	'deploy:setup',
	'deploy:lock',
	'deploy:release',

	'deploy:copy_dirs',
	'deploy:copy',

	'deploy:shared',
	'deploy:writable',

	'deploy:symlink',

	'deploy:unlock',
	'deploy:cleanup',
	'deploy:success',
]);

after('deploy:failed', 'deploy:unlock');

config:
    ssh_type: native
    ssh_multiplexing: true

    remote_user: web-xy-abc
    identityFile: /path/to/key
    deploy_path: /var/www/someplace

    shared_files:
        - config/local.neon

    shared_dirs:
        - log
        - data

    writable_dirs:
        - log
        - temp
        - data


hosts:
    production:
        labels:
            stage: production
        hostname: x.x.x.x

[dakur]

I added clarification – it's not about version of deployer, but about when the deploy happens.

[alexgit2k]

@dakur Try trailing slashes for the shared-directories at writable_dirs:

    writable_dirs:
        - log/
        - temp
        - data/

[dakur]

That works, thank you very much!

[antonmedv]

Maybe deployer needs to warn in no / at the end?

Pr?

[antonmedv]

Looks like this is not a Deployer issue, but your specific issue with your setup.

Converting to a discussion.

[dakur]

I'm quite conifident it's not an issue in my setup, but not 100% sure. Let's wait if someone else runs into this.

[antonmedv]

Now Deployer has different writeable strategy: sticky. Try to use it.

[dakur]

Oh, I didn't know about writable_mode option. I'll try writable_mode: skip, that might work. Thank you very much.

[tinpansoul]

Hi! Anyone have idea of why this is happening and how to workaround? Even if it's about my configuration, then can you help and give me an idea what should i do?

I was using 5.x-6.x versions for many years, now after upgrade to 7.x have same problem problem when deploying for the first time on a machine.
If i downgrade to 6.x version, deploy works. Then if i deploy with new 7.x version – everything works too.

Note that i have file public/icons/.gitignore commited in the repository.

deployer.php:

set('shared_dirs', [
    'public/icons',
    'public/images',
]);
set('writable_dirs', [
    'public/icons',
    'public/images',
]);

error:

[dev]  error  in writable.php on line 122:
[dev] err setfacl: public/icons/.gitignore: Only directories can have default ACLs
[dev] exit code 1 (General error)

[alexgit2k]

@trogwarz Try trailing slashes at writable_dirs:

set('shared_dirs', [
    'public/icons',
    'public/images',
]);
set('writable_dirs', [
    'public/icons/',
    'public/images/',
]);

[tinpansoul]

Thank you! Yes, this workaround actually works well for my Ubuntu 18.04 LTS.
Agreed on adding this to known bugs too – i was reading it before commenting here.

[alexgit2k]

I tracked this down. The error-message "Only directories can have default ACLs" is printed with acl < 2.2.53 like in CentOS 7 (EOL June 2024) or Ubuntu 18 (EOL April 2023) and happens when following conditions are met:

1. the directory is configured in shared_dirs
2. the directory is configured in writable_dirs.
3. the directory contains at least one file

Workaround: If a trailing slash is added to those directories at writable_dirs, setfacl is working fine and also the correct permissions are set for the link-target.

Regardless of this issue, there is may be a permission-problem when writing into a shared-dir, because the symlink is created with remote_user as owner which may not be the same account as http_user which writes into those directories.

• CentOS 7 with acl 2.2.51 (Fail)

docker run -it --rm centos:7 /bin/bash
mkdir -p /test/htdocs/ /test/shared/uploads/
touch /test/shared/uploads/pic1.jpg
ln -s /test/shared/uploads /test/htdocs/uploads
setfacl -v
setfacl -dL -m u:nobody:rwX /test/htdocs/uploads

• Rocky Linux 8 with acl 2.2.53 (Work)

docker run -it --rm rockylinux:8 /bin/bash
mkdir -p /test/htdocs/ /test/shared/uploads/
touch /test/shared/uploads/pic1.jpg
ln -s /test/shared/uploads /test/htdocs/uploads
setfacl -v
setfacl -dL -m u:nobody:rwX /test/htdocs/uploads

• Ubuntu 18.04 with acl 2.2.52 (Fail)

docker run -it --rm ubuntu:18.04 /bin/bash
apt update -y && apt install -y acl
mkdir -p /test/htdocs/ /test/shared/uploads/
touch /test/shared/uploads/pic1.jpg
ln -s /test/shared/uploads /test/htdocs/uploads
setfacl -v
setfacl -dL -m u:nobody:rwX /test/htdocs/uploads

• Ubuntu 20.04 with acl 2.2.53 (Work)

docker run -it --rm ubuntu:20.04 /bin/bash
apt update -y && apt install -y acl
mkdir -p /test/htdocs/ /test/shared/uploads/
touch /test/shared/uploads/pic1.jpg
ln -s /test/shared/uploads /test/htdocs/uploads
setfacl -v
setfacl -dL -m u:nobody:rwX /test/htdocs/uploads

[antonmedv]

Awesome debugging! Maybe we should have a check fir required/ as shared dirs?

[alexgit2k]

I think it's not worth a fix. The working version acl 2.2.53 was released 2018, Ubuntu 18 will reach EOL next month, so only CentOS 7 is left for another 16 months, but the workaround will do it.

[antonmedv]

Maybe add it to https://deployer.org/docs/7.x/KNOWN_BUGS