Bug 838447
Summary: | mount --move not working | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Norman Gaywood <ngaywood> |
Component: | policycoreutils | Assignee: | Daniel Walsh <dwalsh> |
Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 18 | CC: | dwalsh, ed.greshko, gansalmon, itamar, jonathan, kernel-maint, madhu.chinakonda, mgrepl |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-03-25 12:41:50 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Norman Gaywood
2012-07-09 06:53:00 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. 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. 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. your /tmp is setup as a tmpfs, which you can change. 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. Are you using pam_namespace? This might be more to do with systemd, which now support privatetmp in the unit files. 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. |