Bug 838447 - mount --move not working
Summary: mount --move not working
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: policycoreutils
Version: 18
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daniel Walsh
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-07-09 06:53 UTC by Norman Gaywood
Modified: 2013-05-22 00:02 UTC (History)
8 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2013-03-25 12:41:50 UTC


Attachments (Terms of Use)

Description Norman Gaywood 2012-07-09 06:53:00 UTC
Description of problem:

The --move option of the mount command does not work in recent F16 kernels


How reproducible:

The following steps worked in kernel 3.2.10-3
Sometime around 3.3.0-4, and maybe before, the final step failed.
The final step still fails in 3.4.4-4.fc16

In Fedora 17, 3.4.4-5.fc17, all the steps work OK

Steps to Reproduce:
 mkdir -p /tmp/testing
 cd /tmp/testing/
 mkdir -p foo bar
 mount -t tmpfs tmpfs foo/
 mount --move foo bar/
  
Actual results:
The final step, mount --move foo bar/ gives this message:

mount: wrong fs type, bad option, bad superblock on /tmp/testing/foo,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so

Expected results:
The mount --move should work as it does in F17 and in early releases of F16

Comment 1 Josh Boyer 2012-09-05 17:49:15 UTC
This is because of the sandbox service.  I ran your testcases on an updated F16 install and hit the same failure.  Then I did "systemctl disable sandbox.service" and rebooted and tried again.  Things worked fine:

[root@localhost ~]#  mkdir -p /tmp/testing
[root@localhost ~]#  cd /tmp/testing/
[root@localhost testing]#  mkdir -p foo bar
[root@localhost testing]#  mount -t tmpfs tmpfs foo/
[root@localhost testing]#  mount --move foo bar/
[root@localhost testing]# uname -a
Linux localhost.localdomain 3.4.9-2.fc16.x86_64 #1 SMP Thu Aug 23 17:51:29 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost testing]# 

This isn't a kernel problem.

Comment 2 Daniel Walsh 2012-09-07 10:29:11 UTC
The sandbox service has been removed from newer Fedora.  If you are not using pam_namespace or sandbox command you can disable this service and mount --move should work fine.

Comment 3 Norman Gaywood 2013-03-25 04:30:56 UTC
This problem seems to have returned in Fedora 18. There is no sandbox in F18 although there does seem to be a pam_namespace but I'm not sure it is being used.

The above test case once again fails:

crate ~ # mkdir -p /tmp/testing
crate ~ # cd /tmp/testing/
crate testing # mkdir -p foo bar
crate testing # mount -t tmpfs tmpfs foo/
crate testing # mount --move foo bar/
mount: wrong fs type, bad option, bad superblock on /tmp/testing/foo,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so
crate testing # 

The equivalent of the above is used when mounting USB drives in an LTSP environment.

Comment 4 Daniel Walsh 2013-03-25 12:41:30 UTC
your /tmp is setup as a tmpfs, which you can change.

Comment 5 Norman Gaywood 2013-05-21 01:37:39 UTC
This comment is for people looking for a clue on how to solve this.


This problem has something to do with pam_namespace. I can make the move mount work with a "mount --make-runbindable /" although that seems like a rather large stick:

# mkdir -p /tmp/testing
# cd /tmp/testing
# mkdir -p foo bar 
# mount -t tmpfs tmpfs foo
# mount --move foo bar 
mount: wrong fs type, bad option, bad superblock on /tmp/testing/foo,
       missing codepage or helper program, or other error
       In some cases useful info is found in syslog - try
       dmesg | tail or so
# mount --make-runbindable /
# mount --move foo bar 
# 

Although "not a bug", I don't know what should be changed in F18 configuration so that I can make remote ltspfs (fuse/sshfs) mounts in a LTSP environment can be "moved" from /tmp to /media.

Comment 6 Daniel Walsh 2013-05-21 15:59:36 UTC
Are you using pam_namespace?  This might be more to do with systemd, which now support privatetmp in the unit files.

Comment 7 Norman Gaywood 2013-05-22 00:02:29 UTC
The same test script above does not depend on /tmp. The mount --move fails no mater what filesystem I run it from. The LTSP application server that I am trying to solve this problem for, uses an ext4 filesystem backed by real disk. I "think" privatetmp is disabled but the fail also happens on /var/tmp, /home and /.

pam_namespace is configured in many /etc/pamd.d/* as:

session    required     pam_namespace.so

Which is how Fedora seems to setup the default. So I presume I using it.

As is probably clear, I have no real idea where this problem is, comment #5 is my first real breakthrough in getting this to work.


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