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
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.