Bug 1007954 - mock: Permission denied when accessing SOURCES folder in userspace
Summary: mock: Permission denied when accessing SOURCES folder in userspace
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: mock
Version: 19
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Clark Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-09-13 15:45 UTC by laurence.mcglashan
Modified: 2020-11-02 22:38 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-01-20 17:57:23 UTC
Type: Bug


Attachments (Terms of Use)

Description laurence.mcglashan 2013-09-13 15:45:00 UTC
Description of problem:


Version-Release number of selected component (if applicable):
mock v1.1.33

How reproducible:
Always

Steps to Reproduce:
1. Install mock v1.1.33 from fedora 19 repository
2. Build an rpm in userspace with sources in the SOURCES/ directory

Actual results:

INFO: Results and/or logs in: /var/lib/mock/fedora-19-x86_64/result
ERROR: [Errno 13] Permission denied: '/home/***/rpmbuild/SOURCES'
Traceback (most recent call last):
  File "/usr/sbin/mock", line 305, in <module>
    def do_buildsrpm(config_opts, chroot, options, args):
  File "/usr/sbin/mock", line 632, in main
    do_buildsrpm(config_opts, chroot, options, args)
  File "/usr/sbin/mock", line 320, in do_buildsrpm
    srpm = chroot.buildsrpm(spec=options.spec, sources=options.sources, timeout=config_opts['rpmbuild_timeout'])
  File "<peak.util.decorators.rewrap wrapping mockbuild.backend.buildsrpm at 0x01AF32A8>", line 3, in buildsrpm
    def buildsrpm(self, spec, sources, timeout): return __decorated(self, spec, sources, timeout)
  File "/usr/lib/python2.7/site-packages/mockbuild/trace_decorator.py", line 70, in trace
    result = func(*args, **kw)
  File "/usr/lib/python2.7/site-packages/mockbuild/backend.py", line 834, in buildsrpm
    shutil.copy(sources, self.makeChrootPath(self.builddir, "SOURCES"))
  File "/usr/lib64/python2.7/shutil.py", line 119, in copy
    copyfile(src, dst)
  File "/usr/lib64/python2.7/shutil.py", line 82, in copyfile
    with open(src, 'rb') as fsrc:
IOError: [Errno 13] Permission denied: '/home/***/rpmbuild/SOURCES'


Additional info:

Looking at backend.py:

    def buildsrpm(self, spec, sources, timeout)

I printed out the following:

    self.builddir = builddir/build
    spec = SPECS/***.spec
    sources = /home/***/rpmbuild/SOURCES

If I make a hardcoded change of sources to "SOURCES" instead of "/home/***/rpmbuild/SOURCES" then mock works fine.

Is this variable supposed to contain the absolute or relative path?

Comment 1 Clark Williams 2013-09-27 22:09:42 UTC
The triple wildcards look really odd. Kind of looks like some globbing or tilde expansion didn't work. 

What's the command line you used when invoking mock to build the SRPM?

Comment 2 laurence.mcglashan 2013-10-02 09:40:09 UTC
Apologies, I used find and replace on my username with ***

The command I'm using to build the SRPM is:

mock -r $MOCK_TARGET \                                                   
        --buildsrpm \                                            
        --spec SPECS/$SPEC_FILE \                           
        --sources=$PWD/SOURCES \    
        > $LOG_FILE 2>&1

Should I be supplying "--sources=SOURCES" instead of the absolute path "$PWD/SOURCES"?

This used to work with mock from fedora 16. The only unusual thing I can think of about our setup is that the file system is nfs mounted.

Comment 3 Clark Williams 2013-10-24 21:44:21 UTC
Your command line looks fine to me.

You may be hitting the problem we have with NFS and root-squash.  Mock has to start out as root and then changes privilege levels for various operations. If it's trying to access files as root on an NFS partition that has rootsquash turned on, then root will be denied access. Mock copies the specfile and sources directory into the build dir (/var/lib/mock/<configname>/root) before actually rebuilding the srpm. 

Does it work if you put the specfile and sources on a local filesystem (it should).

Comment 4 Clark Williams 2014-01-20 17:57:23 UTC
Presuming that you encountered rootsquash NFS issues, since this works fine on a local filesystem.


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