bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#22030: chown permission denied


From: Bernhard Voelker
Subject: bug#22030: chown permission denied
Date: Sat, 28 Nov 2015 10:56:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0

On 11/27/2015 09:50 AM, Catalino Rivera wrote:
> Been dealing with this problem over a month now and been set aside for a 
> while since I have to take of some other important stuff.
> Now I need to fix it due to job requirements.
> I successfully mounted NFS to a ubuntu server and access the file, 
> however, linking this mounted thing to SVN and change the ownership 
> giving a heck of headache, been scrolling all the
> solution in the WWW, but no luck.
> Please help me with this.
> 
> svnadmin create /media/windowsshare/myproject
> 
> # cd /media/windowsshare
> # chown -R www-data: subversion myproject
> 
> "permission denied"

Assaf already gave you the hint to the root_squash option of NFS.
Reading something about ".../windowsshare/" additionally makes me
think that the underlying file system type on the remote machine
may not allow to chown(2), like some *FAT* variants or NFS.

Furthermore, chown(1) - the GNU coreutils tool - is only a wrapper
around the chown(2) system call, so it can only forward the EPERM
error on the long way from the server's file system, the server's
VFS layer including the mount options there, the server's NFS export
settings, the client's mount options.  As you mentioned it is during
your job, this additionally reminds to about ACLs and (maybe LDAP?)
group membership issues.  Thus said, it likely seems to be a
configuration issue somewhere on this way rather than an issue
with the client tool chown(1); and without knowing more about it,
we can't give you more advise.  I for my part would try to have a
talk with the server admin first.

Have a nice day,
Berny





reply via email to

[Prev in Thread] Current Thread [Next in Thread]