Bug 622320 - useradd reports 'operation not supported' for /home/USER/.gnome2
Summary: useradd reports 'operation not supported' for /home/USER/.gnome2
Alias: None
Product: Fedora
Classification: Fedora
Component: shadow-utils   
(Show other bugs)
Version: 13
Hardware: All Linux
Target Milestone: ---
Assignee: Peter Vrabec
QA Contact: Fedora Extras Quality Assurance
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2010-08-08 23:05 UTC by Aaron Faanes
Modified: 2011-02-13 08:53 UTC (History)
4 users (show)

Fixed In Version: shadow-utils-
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-02-13 08:53:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output demonstrating this bug (2.10 KB, application/octet-stream)
2010-08-08 23:05 UTC, Aaron Faanes
no flags Details
updated ACL patch (5.30 KB, patch)
2011-02-09 17:16 UTC, Peter Vrabec
no flags Details | Diff

Description Aaron Faanes 2010-08-08 23:05:15 UTC
Created attachment 437490 [details]
Output demonstrating this bug

Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. su -c 'useradd newuser'
Actual results:
useradd: preserving permissions for /home/maid/.gnome2: Operation not supported

Expected results:
no output

Additional info:
This appears to be a regression from shadow-utils-, as 'yum downgrade' fixes this issue.

Comment 1 Peter Vrabec 2010-09-22 09:42:54 UTC
$ su -c 'useradd newuser'

$ id newuser
uid=504(newuser) gid=504(newuser) groups=504(newuser)

$ rpm -q shadow-utils
$ rpm -qf /bin/su 

Sorry I can't reproduce the problem. If it persists feel free to reopen the bug.

Comment 2 Michael J. Hammel 2010-12-09 17:44:44 UTC
This bug is still in F14 but I don't have permission to reopen this bug.  It is most likely the same one as Bug 648018.  The problem is that when adding a new user with useradd the files from /etc/skel are not copied into the new users home directory because of the encountered error.  In my case, the error is slightly different:

mjhammel(tty57)$ sudo useradd -c"Matlab User" -d/home/matlab -m -s/bin/bash -g3139 matlab 
useradd: preserving permissions for /home/matlab/.mozilla: Operation not supported

The .mozilla directory is copied to the new users home but none of the rest of the /etc/skel files have been copied into that directory.

mjhammel(tty57)$ sudo ls -al /home/matlab
total 16
drwx------   3 matlab matlab 4096 Dec  9 10:13 .
drwxr-xr-x. 15 root   root   4096 Dec  9 10:13 ..
drwxr-xr-x   2 matlab matlab 4096 Dec  9 10:13 .mozilla

Running strace on the binary shows the following:
access("/etc/skel", F_OK)               = 0
access("/home/matlab", F_OK)            = 0
getdents(10, /* 8 entries */, 32768)    = 248
lstat("/etc/skel/.mozilla", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
mkdir("/home/matlab/.mozilla", 040755)  = 0
chown("/home/matlab/.mozilla", 3139, 3139) = 0
stat("/etc/skel/.mozilla", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
getxattr("/etc/skel/.mozilla", "system.posix_acl_access", 0x7fffc5542350, 132) = -1 ENODATA (No data available)
stat("/etc/skel/.mozilla", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
setxattr("/home/matlab/.mozilla", "system.posix_acl_access", "\x02\x00\x00\x00\x01\x00\x07\x00\xff\xff\xff\xff\x04\x00\x05\x00\xff\xff\xff\xff \x00\x05\x00\xff\xff\xff\xff", 28, 0) = -1 EOPNOTSUPP (Operation not supported)
chmod("/home/matlab/.mozilla", 040755)  = 0
getxattr("/etc/skel/.mozilla", "system.posix_acl_default", 0x7fffc5542350, 132) = -1 ENODATA (No data available)
stat("/etc/skel/.mozilla", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
removexattr("/home/matlab/.mozilla", "system.posix_acl_default") = -1 EOPNOTSUPP (Operation not supported)
write(2, "useradd: ", 9)                = 9
write(2, "preserving permissions for /home"..., 48) = 48
write(2, ": ", 2)                       = 2
write(2, "Operation not supported\n", 24) = 24

Is it possible this is related to the fact that I don't have SELinux enabled?  If not, why are we looking for extended attributes (ACL related, apparently) on these files?  Since there are no extended attributes the ENOTSUP should not cause the process to fail, but apparently it does.

My system is F14 x86-64:
mjhammel(tty57)$ rpm -qf /usr/sbin/useradd

Peter's version of useradd is the same but on different Fedora releases (12 vs 13/14).  Looks like F12 worked but anything after that broke.  At least for some people.

Comment 3 Michael J. Hammel 2011-01-31 18:28:52 UTC
The workaround is to make the directory manually and then copy in the skeleton files manually:

mkdir /home/blah
cp -ar /etc/skel/.{a-z}* /home/blah

Then change the owner/group manually:

chown -R <userid>.<groupid> /home/blah

Comment 4 Kevin Fenzi 2011-01-31 21:51:09 UTC
reopening, per comment 2.

Comment 5 Peter Vrabec 2011-02-09 17:16:11 UTC
Created attachment 477867 [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

Comment 6 Fedora Update System 2011-02-10 10:51:20 UTC
shadow-utils- has been submitted as an update for Fedora 14.

Comment 7 Fedora Update System 2011-02-10 21:30:01 UTC
shadow-utils- has been pushed to the Fedora 14 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update shadow-utils'.  You can provide feedback for this update here: https://admin.fedoraproject.org/updates/shadow-utils-

Comment 8 Fedora Update System 2011-02-13 08:52:51 UTC
shadow-utils- has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.