Description of problem: I created two shared folders /home/.test and /home/test and assigned it to the group "test". Added an user to the group "test". Mounted /home/.test on /home/test using ecryptfs. Added the entry in fstab and modified adding "user" and "group" options. Mounting it as root work flawlessly. Trying to mount as user does not work. Version-Release number of selected component (if applicable): kernel version: $ uname -r 4.14.14-300.fc27.x86_64 ecryptfs-utils version Nome : ecryptfs-utils Versione : 111 Rilascio : 7.fc27 Arch : x86_64 Dim. : 608 k Sorgente : ecryptfs-utils-111-7.fc27.src.rpm Repo : @System Dal repo : fedora Sommario : The eCryptfs mount helper and support libraries URL : https://launchpad.net/ecryptfs Licenza : GPLv2+ Descrizione : eCryptfs is a stacked cryptographic filesystem that ships in : Linux kernel versions 2.6.19 and above. This package provides the : mount helper and supporting libraries to perform key management : and mount functions. : : Install ecryptfs-utils if you would like to mount eCryptfs. Steps to Reproduce: ------ AS ROOT # cd /home # mkdir .test test # groupadd test # chgrp test test/ .test/ # usermod -a -G test paolo # chmod 2755 test/ # chmod 2775 .test/ # mount.ecryptfs .test/ test/ (follow terminal instructions) #cat /etc/fstab /home/.test /home/test ecryptfs rw,relatime,user,group,noauto,ecryptfs_fnek_sig=274cdd7386890c3e,ecryptfs_sig=274cdd7386890c3e,ecryptfs_cipher=aes,ecryptfs_key_bytes=32,ecryptfs_unlink_sigs 0 0 # reboot # ecryptfs-add-passphrase Passphrase: Inserted auth tok with sig [274cdd7386890c3e] into the user session keyring # mount -i /home/.test works as expected ------ AS NORMAL USER (PAOLO) $ groups paolo paolo : paolo wheel idocumenti test $ ecryptfs-add-passphrase Passphrase: Inserted auth tok with sig [274cdd7386890c3e] into the user session keyring $ mount -i /home/.test/ mount: /home/test: mount(2) system call failed: No such file or directory. Additional info: Tried with the same configuration on a virtual machine running Debian 9 and it works as expected.
You could try to mount with ecryptfs-simple instead.
(In reply to Raphael Groner from comment #1) > You could try to mount with ecryptfs-simple instead. I don't know what ecryptfs-simple actually does. In the meantime i tried the same step on Arch and openSuse Tumbleweed and both of them worked like a charm.
Might be an issue with wrong ACL then, propably SELinux related. Please check the logs.
Hi Raphael, sorry for replying after so long. I've been a bit busy. I installed Fedora Workstation 28 in gnome-boxes. The same bug also affected this version. I'm not that expert to provide you the file you need. Which log do I read?
First, please verify enabled SELinux in /etc/selinux/config . Then you can monitor seaudit for new entries. https://docs-old.fedoraproject.org/en-US/Fedora/11/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-Enabling_and_Disabling_SELinux.html https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/SELinux_Guide/rhlcommon-section-0105.html
Issues with SELinux seem to be quite common, bug #1481481.
Done as you said in comment #5 I can't find seaudit in Fedora 28. I looked /var/log/audit/audit.log. tail -n 3 /var/log/audit/audit.log type=USER_ACCT msg=audit(1530450665.434:280): pid=12717 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="root" exe="/usr/bin/su" hostname=localhost.localdomain addr=? terminal=pts/0 res=success' type=CRED_ACQ msg=audit(1530450665.435:281): pid=12717 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:setcred grantors=pam_unix,pam_ecryptfs acct="root" exe="/usr/bin/su" hostname=localhost.localdomain addr=? terminal=pts/0 res=success' type=USER_START msg=audit(1530450665.443:282): pid=12717 uid=1000 auid=1000 ses=3 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:session_open grantors=pam_keyinit,pam_keyinit,pam_limits,pam_ecryptfs,pam_systemd,pam_unix,pam_umask acct="root" exe="/usr/bin/su" hostname=localhost.localdomain addr=? terminal=pts/0 res=success' I can not understand the meaning of these lines.
UPDATE: I completely disabled selinux and tried to mount /home/test with same result. I don't know if it is a useful information.
Also enabling again selinux and trying the mounting procedure returns the same error. Checked /var/log/audit/audit.log with: # tail /var/log/audit/audit.log | grep denied but no result. It seems to me that selinux is not preventing any access to the shared folder. Is this a selinux related problem? I'm currently using Arch due to this bug. I can try to enable selinux ad looking what happens...
TBH it's doubtful we can fix in Fedora as downstream what you expect. The usual howotos suggest to assign the specific user to it's folder, no idea if it should work for groups in any case. Maybe try to ask upstream for a RFE.
This message is a reminder that Fedora 28 is nearing its end of life. On 2019-May-28 Fedora will stop maintaining and issuing updates for Fedora 28. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '28'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 28 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.