chroot + mount = EBUSY

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP











up vote
1
down vote

favorite












I have a large, complex application. I'm trying to run it from a boot CD, which is obviously read-only. But the application needs a large writable area. (A ramdisk won't cut it.) So I've managed to construct a chroot environment to make it look to the application as if it's running from a normal writable environment.



The trouble is, one of the first things the application tries to do is mount some devices that are already mounted. I was expecting the kernel to allow that, but it seems if you try to remount a device with different mount options, the mount(2) call returns EBUSY. I need to make that stop happening.



The application has no idea that it's being run in this slightly strange configuration. I don't really want to change the application code to make this work. Is there some way I can instruct the kernel to pretend to mount something read-only even though it's already mounted somewhere else as read-write?




OK, so people said the question is unclear. Let's try this again:



~# mount /dev/sdb1 /XData
~# mkdir /tmp/CD
~# mount --bind / /tmp/CD
~# mount -t overlayfs -o lowerdir=/tmp/CD,upperdir=/XData/Root,workdir=/XData/Work none /NewRoot
~# chroot /NewRoot
~# java /home/user7/app.jar


Of course, app.jar has no idea that I'm doing this, so it immediately tries to do



mount --ro /dev/sdb1 /XData


which fails. What I'm looking for is a way to make it not fail. I don't really want to alter the application JAR file, but I'm totally OK with altering the commands leading up to launching it. Basically I want app.jar to think everything is normal and nothing weird is happening. But I'm having trouble figuring out how to do that.



(It seems if you try to mount something several times with the same options, the kernel is perfectly fine with that. But trying to mount with different options seems to upset it.)










share|improve this question



















  • 1




    In that environment, can you replace mount by a programme of your own?
    – Gerard H. Pille
    Aug 29 at 9:47










  • @GerardH.Pille That's an interesting suggestion... What are you thinking? Replace it with some kind of script?
    – MathematicalOrchid
    Aug 29 at 9:48










  • If your application is satisfied with a script, that would be the easiest solution. (Has to be executable, of course, and start with a shebang).
    – Gerard H. Pille
    Aug 29 at 9:51











  • This question is simply too fuzzy to be answered sensibly. I'm afraid you have to post more details.
    – countermode
    Aug 29 at 11:25










  • @countermode How do I make is so that stuff mounted outside chroot can be mounted again inside chroot without errors? Seems like a pretty clear question to me...
    – MathematicalOrchid
    Aug 29 at 11:36














up vote
1
down vote

favorite












I have a large, complex application. I'm trying to run it from a boot CD, which is obviously read-only. But the application needs a large writable area. (A ramdisk won't cut it.) So I've managed to construct a chroot environment to make it look to the application as if it's running from a normal writable environment.



The trouble is, one of the first things the application tries to do is mount some devices that are already mounted. I was expecting the kernel to allow that, but it seems if you try to remount a device with different mount options, the mount(2) call returns EBUSY. I need to make that stop happening.



The application has no idea that it's being run in this slightly strange configuration. I don't really want to change the application code to make this work. Is there some way I can instruct the kernel to pretend to mount something read-only even though it's already mounted somewhere else as read-write?




OK, so people said the question is unclear. Let's try this again:



~# mount /dev/sdb1 /XData
~# mkdir /tmp/CD
~# mount --bind / /tmp/CD
~# mount -t overlayfs -o lowerdir=/tmp/CD,upperdir=/XData/Root,workdir=/XData/Work none /NewRoot
~# chroot /NewRoot
~# java /home/user7/app.jar


Of course, app.jar has no idea that I'm doing this, so it immediately tries to do



mount --ro /dev/sdb1 /XData


which fails. What I'm looking for is a way to make it not fail. I don't really want to alter the application JAR file, but I'm totally OK with altering the commands leading up to launching it. Basically I want app.jar to think everything is normal and nothing weird is happening. But I'm having trouble figuring out how to do that.



(It seems if you try to mount something several times with the same options, the kernel is perfectly fine with that. But trying to mount with different options seems to upset it.)










share|improve this question



















  • 1




    In that environment, can you replace mount by a programme of your own?
    – Gerard H. Pille
    Aug 29 at 9:47










  • @GerardH.Pille That's an interesting suggestion... What are you thinking? Replace it with some kind of script?
    – MathematicalOrchid
    Aug 29 at 9:48










  • If your application is satisfied with a script, that would be the easiest solution. (Has to be executable, of course, and start with a shebang).
    – Gerard H. Pille
    Aug 29 at 9:51











  • This question is simply too fuzzy to be answered sensibly. I'm afraid you have to post more details.
    – countermode
    Aug 29 at 11:25










  • @countermode How do I make is so that stuff mounted outside chroot can be mounted again inside chroot without errors? Seems like a pretty clear question to me...
    – MathematicalOrchid
    Aug 29 at 11:36












up vote
1
down vote

favorite









up vote
1
down vote

favorite











I have a large, complex application. I'm trying to run it from a boot CD, which is obviously read-only. But the application needs a large writable area. (A ramdisk won't cut it.) So I've managed to construct a chroot environment to make it look to the application as if it's running from a normal writable environment.



The trouble is, one of the first things the application tries to do is mount some devices that are already mounted. I was expecting the kernel to allow that, but it seems if you try to remount a device with different mount options, the mount(2) call returns EBUSY. I need to make that stop happening.



The application has no idea that it's being run in this slightly strange configuration. I don't really want to change the application code to make this work. Is there some way I can instruct the kernel to pretend to mount something read-only even though it's already mounted somewhere else as read-write?




OK, so people said the question is unclear. Let's try this again:



~# mount /dev/sdb1 /XData
~# mkdir /tmp/CD
~# mount --bind / /tmp/CD
~# mount -t overlayfs -o lowerdir=/tmp/CD,upperdir=/XData/Root,workdir=/XData/Work none /NewRoot
~# chroot /NewRoot
~# java /home/user7/app.jar


Of course, app.jar has no idea that I'm doing this, so it immediately tries to do



mount --ro /dev/sdb1 /XData


which fails. What I'm looking for is a way to make it not fail. I don't really want to alter the application JAR file, but I'm totally OK with altering the commands leading up to launching it. Basically I want app.jar to think everything is normal and nothing weird is happening. But I'm having trouble figuring out how to do that.



(It seems if you try to mount something several times with the same options, the kernel is perfectly fine with that. But trying to mount with different options seems to upset it.)










share|improve this question















I have a large, complex application. I'm trying to run it from a boot CD, which is obviously read-only. But the application needs a large writable area. (A ramdisk won't cut it.) So I've managed to construct a chroot environment to make it look to the application as if it's running from a normal writable environment.



The trouble is, one of the first things the application tries to do is mount some devices that are already mounted. I was expecting the kernel to allow that, but it seems if you try to remount a device with different mount options, the mount(2) call returns EBUSY. I need to make that stop happening.



The application has no idea that it's being run in this slightly strange configuration. I don't really want to change the application code to make this work. Is there some way I can instruct the kernel to pretend to mount something read-only even though it's already mounted somewhere else as read-write?




OK, so people said the question is unclear. Let's try this again:



~# mount /dev/sdb1 /XData
~# mkdir /tmp/CD
~# mount --bind / /tmp/CD
~# mount -t overlayfs -o lowerdir=/tmp/CD,upperdir=/XData/Root,workdir=/XData/Work none /NewRoot
~# chroot /NewRoot
~# java /home/user7/app.jar


Of course, app.jar has no idea that I'm doing this, so it immediately tries to do



mount --ro /dev/sdb1 /XData


which fails. What I'm looking for is a way to make it not fail. I don't really want to alter the application JAR file, but I'm totally OK with altering the commands leading up to launching it. Basically I want app.jar to think everything is normal and nothing weird is happening. But I'm having trouble figuring out how to do that.



(It seems if you try to mount something several times with the same options, the kernel is perfectly fine with that. But trying to mount with different options seems to upset it.)







mount chroot






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Aug 29 at 16:19

























asked Aug 29 at 9:30









MathematicalOrchid

2,19541642




2,19541642







  • 1




    In that environment, can you replace mount by a programme of your own?
    – Gerard H. Pille
    Aug 29 at 9:47










  • @GerardH.Pille That's an interesting suggestion... What are you thinking? Replace it with some kind of script?
    – MathematicalOrchid
    Aug 29 at 9:48










  • If your application is satisfied with a script, that would be the easiest solution. (Has to be executable, of course, and start with a shebang).
    – Gerard H. Pille
    Aug 29 at 9:51











  • This question is simply too fuzzy to be answered sensibly. I'm afraid you have to post more details.
    – countermode
    Aug 29 at 11:25










  • @countermode How do I make is so that stuff mounted outside chroot can be mounted again inside chroot without errors? Seems like a pretty clear question to me...
    – MathematicalOrchid
    Aug 29 at 11:36












  • 1




    In that environment, can you replace mount by a programme of your own?
    – Gerard H. Pille
    Aug 29 at 9:47










  • @GerardH.Pille That's an interesting suggestion... What are you thinking? Replace it with some kind of script?
    – MathematicalOrchid
    Aug 29 at 9:48










  • If your application is satisfied with a script, that would be the easiest solution. (Has to be executable, of course, and start with a shebang).
    – Gerard H. Pille
    Aug 29 at 9:51











  • This question is simply too fuzzy to be answered sensibly. I'm afraid you have to post more details.
    – countermode
    Aug 29 at 11:25










  • @countermode How do I make is so that stuff mounted outside chroot can be mounted again inside chroot without errors? Seems like a pretty clear question to me...
    – MathematicalOrchid
    Aug 29 at 11:36







1




1




In that environment, can you replace mount by a programme of your own?
– Gerard H. Pille
Aug 29 at 9:47




In that environment, can you replace mount by a programme of your own?
– Gerard H. Pille
Aug 29 at 9:47












@GerardH.Pille That's an interesting suggestion... What are you thinking? Replace it with some kind of script?
– MathematicalOrchid
Aug 29 at 9:48




@GerardH.Pille That's an interesting suggestion... What are you thinking? Replace it with some kind of script?
– MathematicalOrchid
Aug 29 at 9:48












If your application is satisfied with a script, that would be the easiest solution. (Has to be executable, of course, and start with a shebang).
– Gerard H. Pille
Aug 29 at 9:51





If your application is satisfied with a script, that would be the easiest solution. (Has to be executable, of course, and start with a shebang).
– Gerard H. Pille
Aug 29 at 9:51













This question is simply too fuzzy to be answered sensibly. I'm afraid you have to post more details.
– countermode
Aug 29 at 11:25




This question is simply too fuzzy to be answered sensibly. I'm afraid you have to post more details.
– countermode
Aug 29 at 11:25












@countermode How do I make is so that stuff mounted outside chroot can be mounted again inside chroot without errors? Seems like a pretty clear question to me...
– MathematicalOrchid
Aug 29 at 11:36




@countermode How do I make is so that stuff mounted outside chroot can be mounted again inside chroot without errors? Seems like a pretty clear question to me...
– MathematicalOrchid
Aug 29 at 11:36










1 Answer
1






active

oldest

votes

















up vote
1
down vote













This script should work for you. If it doesn't, please let me know the mount log messages written to /var/log/user.log, /var/log/syslog or /var/log/messages.



#!/bin/bash
#
# Mount should be a no-op if called as "mount --ro /dev/sdb1 /XData"
#
# Move the real /usr/bin/mount to /usr/bin/mount.bin, and install this
# script as /usr/bin/mount
########################################################################
#
if [[ "$*" == '--ro /dev/sdb1 /XData' ]]
then
logger -t mount "NO-OP: $0 $*"
exit 0
fi

logger -t mount "Action: $0 $*"
exec "$0.bin" "$@"
exit 1





share|improve this answer




















  • Why not exit $? instead of exit 1?
    – pixelomer
    Sep 11 at 20:05










  • @pixelomer I've used exit 1 because it makes little sense to return failure codes of exec from a script pretending to be mount.
    – roaima
    Sep 11 at 20:18










Your Answer







StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "106"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);

else
createEditor();

);

function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: false,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);



);













 

draft saved


draft discarded


















StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f465461%2fchroot-mount-ebusy%23new-answer', 'question_page');

);

Post as a guest






























1 Answer
1






active

oldest

votes








1 Answer
1






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
1
down vote













This script should work for you. If it doesn't, please let me know the mount log messages written to /var/log/user.log, /var/log/syslog or /var/log/messages.



#!/bin/bash
#
# Mount should be a no-op if called as "mount --ro /dev/sdb1 /XData"
#
# Move the real /usr/bin/mount to /usr/bin/mount.bin, and install this
# script as /usr/bin/mount
########################################################################
#
if [[ "$*" == '--ro /dev/sdb1 /XData' ]]
then
logger -t mount "NO-OP: $0 $*"
exit 0
fi

logger -t mount "Action: $0 $*"
exec "$0.bin" "$@"
exit 1





share|improve this answer




















  • Why not exit $? instead of exit 1?
    – pixelomer
    Sep 11 at 20:05










  • @pixelomer I've used exit 1 because it makes little sense to return failure codes of exec from a script pretending to be mount.
    – roaima
    Sep 11 at 20:18














up vote
1
down vote













This script should work for you. If it doesn't, please let me know the mount log messages written to /var/log/user.log, /var/log/syslog or /var/log/messages.



#!/bin/bash
#
# Mount should be a no-op if called as "mount --ro /dev/sdb1 /XData"
#
# Move the real /usr/bin/mount to /usr/bin/mount.bin, and install this
# script as /usr/bin/mount
########################################################################
#
if [[ "$*" == '--ro /dev/sdb1 /XData' ]]
then
logger -t mount "NO-OP: $0 $*"
exit 0
fi

logger -t mount "Action: $0 $*"
exec "$0.bin" "$@"
exit 1





share|improve this answer




















  • Why not exit $? instead of exit 1?
    – pixelomer
    Sep 11 at 20:05










  • @pixelomer I've used exit 1 because it makes little sense to return failure codes of exec from a script pretending to be mount.
    – roaima
    Sep 11 at 20:18












up vote
1
down vote










up vote
1
down vote









This script should work for you. If it doesn't, please let me know the mount log messages written to /var/log/user.log, /var/log/syslog or /var/log/messages.



#!/bin/bash
#
# Mount should be a no-op if called as "mount --ro /dev/sdb1 /XData"
#
# Move the real /usr/bin/mount to /usr/bin/mount.bin, and install this
# script as /usr/bin/mount
########################################################################
#
if [[ "$*" == '--ro /dev/sdb1 /XData' ]]
then
logger -t mount "NO-OP: $0 $*"
exit 0
fi

logger -t mount "Action: $0 $*"
exec "$0.bin" "$@"
exit 1





share|improve this answer












This script should work for you. If it doesn't, please let me know the mount log messages written to /var/log/user.log, /var/log/syslog or /var/log/messages.



#!/bin/bash
#
# Mount should be a no-op if called as "mount --ro /dev/sdb1 /XData"
#
# Move the real /usr/bin/mount to /usr/bin/mount.bin, and install this
# script as /usr/bin/mount
########################################################################
#
if [[ "$*" == '--ro /dev/sdb1 /XData' ]]
then
logger -t mount "NO-OP: $0 $*"
exit 0
fi

logger -t mount "Action: $0 $*"
exec "$0.bin" "$@"
exit 1






share|improve this answer












share|improve this answer



share|improve this answer










answered Aug 30 at 9:00









roaima

40.5k547110




40.5k547110











  • Why not exit $? instead of exit 1?
    – pixelomer
    Sep 11 at 20:05










  • @pixelomer I've used exit 1 because it makes little sense to return failure codes of exec from a script pretending to be mount.
    – roaima
    Sep 11 at 20:18
















  • Why not exit $? instead of exit 1?
    – pixelomer
    Sep 11 at 20:05










  • @pixelomer I've used exit 1 because it makes little sense to return failure codes of exec from a script pretending to be mount.
    – roaima
    Sep 11 at 20:18















Why not exit $? instead of exit 1?
– pixelomer
Sep 11 at 20:05




Why not exit $? instead of exit 1?
– pixelomer
Sep 11 at 20:05












@pixelomer I've used exit 1 because it makes little sense to return failure codes of exec from a script pretending to be mount.
– roaima
Sep 11 at 20:18




@pixelomer I've used exit 1 because it makes little sense to return failure codes of exec from a script pretending to be mount.
– roaima
Sep 11 at 20:18

















 

draft saved


draft discarded















































 


draft saved


draft discarded














StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f465461%2fchroot-mount-ebusy%23new-answer', 'question_page');

);

Post as a guest













































































Popular posts from this blog

How to check contact read email or not when send email to Individual?

Displaying single band from multi-band raster using QGIS

How many registers does an x86_64 CPU actually have?