Disable auto mounting of drives?

[boxbox]

Is there a way to disable auto mounting of drives so that I can do certain disk operations on both (e.g. dd from one to the other)? I tried to unmount both drives after they get auto mounted and one of the drives isn't possible to umount, because it seems to be used by multiple other processes. Even doing umount with -f flag doesn't work. It's just a regular ext4 disk, formatted on another computer and put into the DNS-323, and doesn't have ipkg or ffp or anything else installed.

I tried shutting off the DNS-323, removing the drives, turning the DNS-323 back on, then putting the disks in after that and it still auto-mounted them. Using the web interface to eject the drive fails also, saying that the device is busy. Any way I could have both drives unmounted while they're within the NAS? Thanks!

[Joao Cardoso]

On Thursday, September 13, 2012 9:17:41 PM UTC+1, boxbox wrote:

Is there a way to disable auto mounting of drives

No

 

so that I can do certain disk operations on both (e.g. dd from one to the other)? I tried to unmount both drives after they get auto mounted and one of the drives isn't possible to umount, because it seems to be used by multiple other processes. Even doing umount with -f flag doesn't work.

If there are running processes with open files on a filesystem, the filesystem can't be unmounted, no matter what.

 

It's just a regular ext4 disk, formatted on another computer and put into the DNS-323, and doesn't have ipkg or ffp or anything else installed.

But some running process must be accessing it.

 

I tried shutting off the DNS-323, removing the drives, turning the DNS-323 back on, then putting the disks in after that and it still auto-mounted them.

That is a feature, don't you agree?

 

Using the web interface to eject the drive fails also, saying that the device is busy. Any way I could have both drives unmounted while they're within the NAS? Thanks!

Yes, stop all services, System->Utilities->Services->StopAll

Some services will "resurrect":  udhcpc (if you are not using a static IP, and that can be a problem), syslogd, klogd, sysctrl (fan, leds, etc) and inetd (ssh/telnet/httpd/...). 

But as you are a command line guy you can always do a 'ps' and 'kill' any process you want. Better yet, use 'rcall status', then 'rc<service> stop' to cleanly stop services. You might have also to turn off swapping  on the offending disk, but then you will only have a few tens of system memory to work with.

If that still doesn't work, post the output of 'aufs.sh -l', 'mount', 'cat /proc/swaps', and please say what disk/filesystem is not unmounting.

[Rolf Larsson]

One of my 3TB disks got accidentally* ejected while it was formatting, and if I insert it pretty much everything hangs; web UI hangs, I can't ssh into the box (or if I can, doing anything related to disk control will hang), existing ssh connections die on certain commands etc. I suppose I'll need to put the disk into a USB cabinet and wipe the partition table from another linux box.

Some kind of 'rescue' mode might be interesting to pursue at a (much) later stage.

-- R

*) Too much gefingerpoken by yours truly...

[Joao Cardoso]

I see... better, I don't see.
I mean, I can't fix it if I don't know what's wrong.

Do you have any Alt-F packages installed? Even if not using it?
Can you telnet? While the system don't hang, can you get any filesystem status? Such as 'mount', 'aufs.sh -l', 'du -h /tmp', 'cat /proc/swaps', 'logread', 'dmesg' , ...

The more factual info I get, even if partial, the more probable is that I find a fix.

As for the "recovery", which is a good idea, the problem is the same, recovering from what? Doing what?

Thanks.

On Sep 22, 2012 9:19 PM, "Rolf Larsson" <rolf.l...@gmail.com> wrote:

One of my 3TB disks got accidentally* ejected while it was formatting, and if I insert it pretty much everything hangs; web UI hangs, I can't ssh into the box (or if I can, doing anything related to disk control will hang), existing ssh connections die on certain commands etc. I suppose I'll need to put the disk into a USB cabinet and wipe the partition table from another linux box.

Some kind of 'rescue' mode might be interesting to pursue at a (much) later stage.

-- R

*) Too much gefingerpoken by yours truly...

On Friday, September 14, 2012 2:19:13 PM UTC+2, Joao Cardoso wrote: > > > > On Thursday, September...

-- You received this message because you are subscribed to the Google Groups "Alt-F" group. To post...

To view this discussion on the web visit https://groups.google.com/d/msg/alt-f/-/AYn33HdXZ1kJ.
 
 

[scaramanga]

Sorry to bring back this old-ish post back to life, but I'm trying to do the same thing: disable autu-mounting all partitions.
My situation is as following: I have a DNS-323 with fw 1.10 and am using ALT-F.01RC2 reloaded with 2 WD 1TB drives in standard mode.
Since I didn't make any changes to the default partitioning scheme I have the 4 ext3 partitions (2 on each drive) - you know with those little 500MB partitions for the printer queue or whatever.

What I'd like to do is stop those little partitions from auto mounting. What I did was under Disk->Filesystems I changed sda4's and sdb4's mount options to noauto (from default). I saved the settings (in System->Settings).

The problem is, after a power out, when I powered the DNS-3232 up again these settings were saved, but those two partitions were auto-mounted.
Here's the /etc/fstab file:

#
# cat /etc/fstab
#
/dev/sda1 none swap pri=1 0 0
/dev/sda2 /mnt/sda2 ext3 defaults 0 0
/dev/sdb1 none swap pri=1 0 0
/dev/sdb2 /mnt/sdb2 ext3 defaults 0 0
/dev/sda4 /mnt/sda4 ext3 noauto 0 0
/dev/sdb4 /mnt/sdb4 ext3 noauto 0 0
#

[Joao Cardoso]

On Sunday, January 6, 2013 10:35:33 AM UTC, scaramanga wrote:

Sorry to bring back this old-ish post back to life, but I'm trying to do the same thing: disable autu-mounting all partitions.

Currently not possible, as fstab is rebuild at each boot, depending on the detected fs/disks.

Mount options are preserved using the filesystem uuid, but they are not parsed or followed (the noauto option could be followed, please fill-in a issue request, but that will be low priority)

As a matter of fact I find the small 500MB partitions useful; I use them to install Alt-F and ffp packages. That has several non-obvious positive impact on the system (fs operations on the user's main filesystem, such as unmount, fsck, convert, to name a few).

[scaramanga]

On Sunday, January 6, 2013 11:16:04 PM UTC+2, Joao Cardoso wrote:

On Sunday, January 6, 2013 10:35:33 AM UTC, scaramanga wrote:

Sorry to bring back this old-ish post back to life, but I'm trying to do the same thing: disable autu-mounting all partitions.

Currently not possible, as fstab is rebuild at each boot, depending on the detected fs/disks.

Mount options are preserved using the filesystem uuid, but they are not parsed or followed (the noauto option could be followed, please fill-in a issue request, but that will be low priority)

 

I'll fill in the issue.
How about changing the default mount options using tune2fs -o. Will that work? Currently, it seems, the mount options are empty.
Oh, and while we're at it: In a different discussion you suggested adding the journal_data_ordered mount option to existing ext3 partitions, either by adding them to the disk->filesystems or using tune2fs. The disk->filesystems method won't survive a reboot, right? I should use tune2fs to do that too.

As a matter of fact I find the small 500MB partitions useful; I use them to install Alt-F and ffp packages. That has several non-obvious positive impact on the system (fs operations on the user's main filesystem, such as unmount, fsck, convert, to name a few).

 

*Sigh* now why didn't I think of that.

[Joao Cardoso]

On Monday, January 7, 2013 8:10:21 AM UTC, scaramanga wrote:

On Sunday, January 6, 2013 11:16:04 PM UTC+2, Joao Cardoso wrote:

On Sunday, January 6, 2013 10:35:33 AM UTC, scaramanga wrote:

Sorry to bring back this old-ish post back to life, but I'm trying to do the same thing: disable autu-mounting all partitions.

Currently not possible, as fstab is rebuild at each boot, depending on the detected fs/disks.

Mount options are preserved using the filesystem uuid, but they are not parsed or followed (the noauto option could be followed, please fill-in a issue request, but that will be low priority)

 

I'll fill in the issue.

Thanks. I took a look and it was so simple to implement that I have already done it (for the next release/snapshot)

But If you try to mount the fs using Disk->Filesystem, Mount, it will not be mounted, you will have to remove the "noauto" option first. Perhaps not what you expect, but...

How about changing the default mount options using tune2fs -o. Will that work? Currently, it seems, the mount options are empty.

I don't think so, that is for fs specific ext2/3/4 options, not generic ones, see the man page.

 

Oh, and while we're at it: In a different discussion you suggested adding the journal_data_ordered mount option to existing ext3 partitions, either by adding them to the disk->filesystems or using tune2fs. The disk->filesystems method won't survive a reboot, right?

They survive and will be used, so you can use it as described in the post you refer to.

The "noauto" was the "exception".

When you specify a fs mount option in Filesystem Maintenance, the entered options are saved in /etc/misc.conf together with the fs uuid and saved in flash memory.

When latter the same fs is recognized (by its uuid), the flash-saved options are used when (re)creating the fstab entry.

This means that you can remove a disk, insert another, then reinsert the first, and still the specified options for the first disk will be used

/ # blkid /dev/sdb4

/dev/sdb4: UUID="39f62682-4286-4136-a9bc-05cc85511d7e" TYPE="ext4"

/ # cat /etc/misc.conf 

...

mopts_39f62682_4286_4136_a9bc_05cc85511d7e=defaults,noauto

/ # cat /etc/fstab 

...

/dev/sdb4 /mnt/sdb4 ext4 defaults,noauto 0 0

The above applies to any mount option specified in Filesystem Maintenance (and overrides the ones specified by using tune2fs)

I should use tune2fs to do that too.

You can. It will keep misc.conf cleaner.

 

...

As a matter of fact I find the small 500MB partitions useful; I use them to install Alt-F and ffp packages. That has several non-obvious positive impact on the system (fs operations on the user's main filesystem, such as unmount, fsck, convert, to name a few).

 

*Sigh* now why didn't I think of that.

Try the attached script to move the current Alt-F installation to a new filesystem.

Download it to, e.g. /root, make it executable using 'chmod +x Alt-F-reloc.sh', stop all services and invoke it. The current installation will be renamed to 'Alt-F-orig'.

Any issues? It worked for me on a simple installation.

I could offer a "Move Installation" option in the Alt-F package manager web page?...

[scaramanga]

On Monday, January 7, 2013 6:50:13 PM UTC+2, Joao Cardoso wrote:

 

As a matter of fact I find the small 500MB partitions useful; I use them to install Alt-F and ffp packages. That has several non-obvious positive impact on the system (fs operations on the user's main filesystem, such as unmount, fsck, convert, to name a few).

 

*Sigh* now why didn't I think of that.

Try the attached script to move the current Alt-F installation to a new filesystem.

Download it to, e.g. /root, make it executable using 'chmod +x Alt-F-reloc.sh', stop all services and invoke it. The current installation will be renamed to 'Alt-F-orig'.

Any issues? It worked for me on a simple installation.

I could offer a "Move Installation" option in the Alt-F package manager web page?...

It'll have to wait for a bit, I'm afraid. My current priority is to update my rsync-based incremental-auto-rotating backup script to Alt-F. It should be easy enough, except the email rsync log file as attachment part - it uses mutt for that. With Alt-F there's sendmail but no uuencode to handle attachments
But that's a matter for different topic, perhaps.

Thanks for your help - you rock!