Flooded logs: sem_get(): Failed for key 0x7ea: Permission denied at /var/www/html/nextcloud/lib/private/Preview/Generator.php#272

[fuzunspm]

I'm getting the below error even after removing preview generator

sem_get(): Failed for key 0x7ea: Permission denied at /var/www/html/nextcloud/lib/private/Preview/Generator.php#272

[rwez]

+1

[joshtrichards]

This isn't coming from the previewgenerator app (though it may be getting triggered by it I guess).

This is a Nextcloud Server matter, but I have no idea offhand why you'd be getting permission denied from sem_get.

Are you still seeing this? If so, please share the output of occ config:list system since it is related to the preview concurrency mode/ configuration.

I'll also go ahead and move this over to the appropriate repository.

[Nicosss]

Problem is still present −> sem_get(): Failed for key 0x7ea: Permission denied at /var/www/nextcloud/lib/private/Preview/Generator.php#230

occ config:list system output:

{
    "system": {
        "instanceid": "***REMOVED SENSITIVE VALUE***",
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "cloud.***REMOVED***"
        ],
        "datadirectory": "***REMOVED SENSITIVE VALUE***",
        "dbtype": "mysql",
        "version": "29.0.0.19",
        "overwrite.cli.url": "https:\/\/cloud.***REMOVED***",
        "dbname": "***REMOVED SENSITIVE VALUE***",
        "dbhost": "***REMOVED SENSITIVE VALUE***",
        "dbport": "",
        "dbtableprefix": "oc_",
        "mysql.utf8mb4": true,
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "filelocking.enabled": true,
        "memcache.local": "\\OC\\Memcache\\APCu",
        "memcache.distributed": "\\OC\\Memcache\\Redis",
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "***REMOVED SENSITIVE VALUE***",
            "port": 6379,
            "dbindex": 0,
            "password": "***REMOVED SENSITIVE VALUE***",
            "timeout": 1.5
        },
        "default_phone_region": "FR",
        "mail_smtpmode": "smtp",
        "mail_smtpsecure": "tls",
        "mail_sendmailmode": "smtp",
        "mail_from_address": "***REMOVED SENSITIVE VALUE***",
        "mail_domain": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtphost": "***REMOVED SENSITIVE VALUE***",
        "mail_smtpport": "587",
        "mail_smtpauth": 1,
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***",
        "maintenance": false,
        "maintenance_window_start": 1,
        "theme": "",
        "loglevel": 2,
        "twofactor_enforced": "false",
        "twofactor_enforced_groups": [],
        "twofactor_enforced_excluded_groups": [],
        "app_install_overwrite": [
            "quicknotes"
        ]
    }
}

[Remendado]

Problem is still present −> sem_get(): Failed for key 0x7ea: Permission denied at /var/www/nextcloud/lib/private/Preview/Generator.php#230

Same problem

[joshtrichards]

Best guess:

• SELinux
• Something OS specific (e.g. you're running under FreeBSD or maybe WSL)

[HeyHagen]

I'm getting the below error even after removing preview generator

sem_get(): Failed for key 0x7ea: Permission denied at /var/www/html/nextcloud/lib/private/Preview/Generator.php#272

I have the same problem running nextcloud 28.0.5 on FreeBSD 13.3

[Nicosss]

Best guess:

* SELinux

* Something OS specific (e.g. you're running under FreeBSD or maybe WSL)

I found a SELinux AVC in the system logs. This problem appeared with the update from NC 28.0.4.1 to 29.0.0.19. For information, the OS is Fedora Linux. I'll report this bug to https://bugzilla.redhat.com/ .

SELinux is preventing php-fpm from 'unix_read, unix_write' accesses on the semaphore Inconnu.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that php-fpm should be allowed unix_read unix_write access on the Inconnu sem by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'php-fpm' --raw | audit2allow -M my-phpfpm
# semodule -X 300 -i my-phpfpm.pp


Additional Information:
Source Context                system_u:system_r:httpd_t:s0
Target Context                system_u:system_r:unconfined_service_t:s0
Target Objects                Inconnu [ sem ]
Source                        php-fpm
Source Path                   php-fpm
Port                          <Unknown>
Host                          REMOVED
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-39.5-1.fc39.noarch
Local Policy RPM              selinux-policy-targeted-39.5-1.fc39.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     REMOVED
Platform                      Linux REMOVED 6.8.7-200.fc39.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Apr 17 19:35:11 UTC 2024
                              x86_64
Alert Count                   231
First Seen                    2024-04-24 19:47:49 CEST
Last Seen                     2024-05-02 21:06:07 CEST
Local ID                      cc0e7076-dbd4-4d2c-ae9d-008cf2c7eca7

Raw Audit Messages
type=AVC msg=audit(1714676767.794:12803): avc:  denied  { unix_read unix_write } for  pid=356188 comm="php-fpm" ipc_key=2026  scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:unconfined_service_t:s0 tclass=sem permissive=0


Hash: php-fpm,httpd_t,unconfined_service_t,sem,unix_read,unix_write

[sam-harry]

I have the same problem running nextcloud 28.0.5 on FreeBSD 13.3

In a FreeBSD jail, you have to set sysvsem = new; in your jail.conf so that "the jail will have its own key namespace, and can only see the objects that it has create" from the jail(8) man page.

[Nicosss]

I found a SELinux AVC in the system logs. This problem appeared with the update from NC 28.0.4.1 to 29.0.0.19.

To be sure, I checked that I had applied all the first recommendations from https://docs.nextcloud.com/server/latest/admin_manual/installation/selinux_configuration.html and it was all good.

I just redid restorecon -Rv '/var/www/html/nextcloud/' pointing to my own installation and after updating a kernel I rebooted. Since then, I haven't had this error, nor the SELinux AVC mentioned.

I'll keep checking to see if it appears again.

[HeyHagen]

I have the same problem running nextcloud 28.0.5 on FreeBSD 13.3

In a FreeBSD jail, you have to set sysvsem = new; in your jail.conf so that "the jail will have its own key namespace, and can only see the objects that it has create" from the jail(8) man page.

Thank you! It seems that the error is no longer present after activating sysvsem=new for my nextcloud jail.

[nextcloud-command]

This issue has been automatically marked as stale because it has not had recent activity and seems to be missing some essential information. It will be closed if no further activity occurs. Thank you for your contributions.

[Sebastian-Roth]

Just migrated a Nextcloud setup from an old server to a fresh new system and also updated to 29.0.3 (was 28.0.6) in the same move. On this new server we now have the described issue (nextcloud.log: sem_get(): Failed for key 0xa11: Permission denied / audit.log: avc: denied { unix_read unix_write } for pid=65042 comm="php-fpm" ipc_key=2577 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 tclass=sem permissive=0)

Running restorecon -Rv '/var/www/html/nextcloud/' has not fixed the issue for me. Followed the recommendations from https://docs.nextcloud.com/server/latest/admin_manual/installation/selinux_configuration.html again and can't see what I could have wrong.

@Nicosss did you get to open the bug report with RedHat? Searching bugzilla and the web didn't yield suitable results so far.

[amessina]

@Sebastian-Roth in my limited testing, this occurs since both occ and nextcloud cron/systemd.timer run via php's cli interface and unconfined whereas the server runs confined as httpd_t. If occ or nextcloud cron run first, the semaphores are created with the unconfined_service_t label. I don't see a way to change this without writing an entire custom policy for /usr/bin/php, which on my Fedora 40 system is labeled as bin_t and has no targeted policy.

Unfortunately, this leaves us with the following:

allow httpd_t unconfined_service_t:sem rw_sem_perms;