Description of problem: No file in /etc/skel is copied by useradd This is a regression by https://bugzilla.redhat.com/show_bug.cgi?id=513055. This bugzilla introduced a feature to copy acl information of files with libacl. This problem doesn't occur on RHEL 5.5, but it occurs on RHEL5.6. But, in case that any filesystem is mounted on /home without acl option, it fails to copy (set) acl information to a home directory in /home. It seems that the root filesystem can deal with acl by default. I guess that it's related with selinux enabled. So, when /home is in the root filesystem, this problem doesn't occur. useradd fails and exits on the way when it tries to copy the acl information of *directory*. It calls perm_copy_file() in libacl to copy the directory and it returns a value except for 0. On the other hand, when it copies the acl information of regular file, it calls perm_copy_fd() in libacl. Although it fails to copy the acl information as a case of directory, it can copy the file mode successfully and it returns 0 meaning "no error". So, in case of regular file, it can proceed forward. I am still not sure we should fix this issue in shadow-utils or acl package. If we can fix it in shadow-utils, we need to check if acl is enabled on the filesystem including /home before calling perm_copy_file(). Version-Release number of selected component (if applicable): Red Hat Enterprise Linux 5.6 shadow-utils-4.0.17-18.el5 How reproducible: Always Steps to Reproduce: 1. install RHEL 5.6 2. make the filesystem for /home and mount it without acl option 3. useradd tester Actual results: The following error is outputed and all files in /etc/skels are not copied. copydir(): preserving permissions for /home/kikuchi/.kde: Operation not supported Expected results: Even when acl is not enabled in the filesystem on /home, useradd can copy all files and directories in /etc/skels to the home directory of the new user. Additional info:
(In reply to comment #0) > I am still not sure we should fix this issue in shadow-utils or acl package. perm_copy_file() works as expected. It fails with ENOSYS if the operation is not supported. It is up to shadow-utils how it handles the error code, and if it prints any error at all. > If we can fix it in shadow-utils, we need to check if acl is enabled on the > filesystem including /home before calling perm_copy_file(). That feels wrong to me. Better would be to just call perm_copy_file() and then check its result. Otherwise you're introducing unnecessary race condition and problems with unreliable detection of the ACL support.
Created attachment 477851 [details] updated ACL patch this updated solution basically ignore EOPNOTSUPP from perm_copy_file/perm_copy_fd on both levels: 1. error message is not printed 2. return code == 0 I don't know any better way :(
*** Bug 673241 has been marked as a duplicate of this bug. ***
please hurry a patch for this bug, I have to implement a rather complicated workaround in my products right now... :-(
workaround: change the default mount options of /home: ext2/3: tune2fs <mountpoint> -o user_xattr,acl ext4: tune4fs <mountpoint> -o user_xattr,acl remount: mount /home -o remount,user_xattr,acl
Got the same problem using a GFS2 volume as the "/home" directory for my users. Directories from /etc/skel are created by "useradd" but no files are copied: copydir(): preserving permissions operation for *OMITTED* not supported Using a ext3 volume for a home directory works OK. Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 5.6 (Tikanga) Release: 5.6 Codename: Tikanga
Any progress on this? I've been forced to roll back to the prior version on my production mail server to get the .procmailrc to copy over to home directories on an external array. Would love to be get back current.
see comment 10
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHBA-2012-0244.html