Trouble with Extra HD @ core 179

Dear All,

Today I upgraded my APU4D4 IPFire Firewall from core 178 to core 179. Everything is working well except the new Extra HD.

I have an EXT4 formatted USB-Stick inserted into the USB port of my APU4D4. Up to and including core 178 I could seamlessly use it with ExtraHD and create a shared Samba drive.

After upgrade to core 179 and reboot, this USB stick was not anymore mounted. ExtraHD was listing it, but flagged it as ‘Not mounted’.

Based on some post in this forum, I’ve then manually deleted the file ‘/var/ipfire/extrahd/devices’.
However, after a reboot this file is not recreated. ExtraHD is not recognizing any device anymore.

The USB stick is OK. I did a file system check at my Linux laptop

Can you help me to get the ExtraHD drive back again, please?

Many thanks in advance.

Best regards,


Per the blog on the release of 179
There was a complete rewrite of the Extra HD plugin.

I read the blog before installing core 179. However, the brand new plugin doesn’t work at my side.
Any hints what I am doing wrongly?

You deleted a file based on a forum post related to the previous version of Extra HD. The file might be doing quite different things now compared to previously.

I just tried plugging in a usb stick into my production IPFire and the stick was found.

I then specified a mount point and pressed the pencil icon and the mount point was created and the stick mounted.

I could then list the contents of the stick.

I then selected the green mounted icon and the drive was unmounted.

So I am not finding any issues.

When you plug in your usb stick and run lsblk from the command line do you see the usb stick listed?

What mount point did you use with the previous version of Extra HD?

Thanks for helping me.

A plugged in USB stick is detected by lsblk:

# lsblk
sda      8:0    0  14.9G  0 disk 
├─sda1   8:1    0   128M  0 part /boot
├─sda2   8:2    0    32M  0 part /boot/efi
├─sda3   8:3    0 981.2M  0 part [SWAP]
└─sda4   8:4    0  13.8G  0 part /
sdb      8:16   1 231.4G  0 disk 
├─sdb1   8:17   1 231.4G  0 part 
└─sdb2   8:18   1     1M  0 part

From my memory, in core178 and before I used ‘/mnt/harddisk’ as mount point.

I found some mysteries:

/lib/udev/rules.d/61-extrahd.rules contains

ACTION=="add", SUBSYSTEM=="block", RUN+="/var/ipfire/extrahd/bin/ udev-event"

However, when I am running “/var/ipfire/extrahd/bin/ udev-event”` from the command line, the error message is

# /var/ipfire/extrahd/bin/ udev-event
/var/ipfire/extrahd/bin/ Unsupported command: udev-event

For me it looks like as if ‘/var/ipfire/extrahd/bin/’ is still the previous core 178 version:
There in no no string ‘udev’ in the file ‘var/ipfire/extrahd/bin/’.

1 Like



Also my expensive bought 4TB SSD hard disk is no longer mounted and there are many data especially my backup.


What do I have to do now so that the hard disk is mounted again under the originals path and and without reformatting of the hard disk is also bad?

Unfortunately my SAMBA share is gone and so is my access to the data.


Do I now have to run mount /dev/sda /mnt/SSD-4TB on every reboot or can I also enter appropriate values in /etc/fstab?


Is only about whether after a reboot that remains from fstab and SAMBA then plays along.

During the CU179 Testing the problem I found was related to LVM volumes. For those, as there is a workaround of adding the info into fstab, it was decided to leave fixing LVM on ExtraHD until after CU179 was released.

@jon then flagged up that some usb sticks were not showing up and it was identified that slow USB sticks were not getting correctly mounted at boot. A commit was done to fix that, at the start of last week, and there has been no feedback since then of further issues so the CU179 Testing has been released today.

As some of you are now flagging further issues found after release then I would suggest the best thing is to add them in as comments to the ExtraHD bug that is currently still open.


I would think you can also add a line for it into fstab. However, I would suggest not using sda nomenclature but the UUID in case adding or removing drives causes the drives to be renamed differently. The UUID is unique for each drive and I have been using those for all my fstab definitions for the last 4 years or so rather than /dev/sda1 etc

1 Like

How would I have to store the entry in fstab if I want to mount the hard disk formatted with the UUID and EXT4 in the path /mnt/SSD-4TB?
Am a bit unpracticed in using fstab

I just spent few hours this week end doing this in a Debian machine. Here my notes on how to do this. In case it is useful.

To create an entry in /etc/fstab using the UUID, follow these steps:

  1. Access the machine via SSH as root.

  2. Run the blkid command to get the UUID:


    Note the UUID for the hard disk you’re interested in.

  3. Open /etc/fstab:

    nano /etc/fstab
  4. Add a new line in /etc/fstab for the hard disk using the UUID. The general format is:

    UUID=your-uuid-goes-here  /mount/point  filetype  options  dump  pass

    For example, if the UUID is 1234-ABCD and you want to mount it at /mnt/mydisk with ext4 filesystem:

    UUID=1234-ABCD  /mnt/mydisk  ext4  defaults  0  0
  5. Save the file and exit the text editor.

  6. Create the mount point directory if it doesn’t exist:

    mkdir -p /mnt/mydisk
  7. Mount the filesystem to verify:

    mount -a

The fstab entry ensures that the disk is mounted at boot or when you run mount -a. The defaults option refers to the default mount options, and 0 0 at the end are for dump and filesystem check options, which are generally safe to leave as zero.

The dump and pass (also called “check”) are the fifth and sixth fields in the /etc/fstab entry, respectively.

  • Dump: The dump field is used by the dump utility to decide if a filesystem should be backed up. If the value is 0, the dump utility will ignore the filesystem. If the value is set to 1, it will be included in the backup. dump is not commonly used these days, so this field is usually set to 0.

  • Pass (Check): The pass field specifies the order in which the fsck utility will check the filesystems at boot time. The root filesystem should have this set to 1, and other filesystems you want to be checked should be set to 2. If this is set to 0, fsck will not check the filesystem. It’s advisable to set the root filesystem to 1 and any additional filesystems to 2 to ensure they’re checked at boot, though not simultaneously, which could slow down the boot process.

In most cases, for additional disks and partitions, setting both dump and pass to 0 is acceptable, which means no backup and no check at boot.

1 Like

Thank you that has helped me for now and maybe there is still a solution to be able to manage this later again via ExtraHD.

You might want to add noatime and nodiratime to the defaults options in fstab. This should help saving writing cycles in your ssd.

UUID=your-uuid-goes-here  /mount/point  filetype  defaults,noatime,nodiratime  dump  pass

Thanks, I have added the two values and there is also a VEEAM backup running on the SSD which causes enough write cycles.

A small note, usually noatime is interpreted as both “no last access time” for files and directories as nodiratime is supposed to be used only if noatime is missing, but I usually add both just in case, as I never found a problem with this redundancy.

@ewald - I have the same issue with CU 179

for me - External SSD connected via USB, EXT4 format, does not mount after reboot, cannot mount via EXTRAHD.

The only indicator of “odd” was the red circle on the right:

For me I deleted the devices in the /var/ipfire/extrahd/devices and then I was able to add a drive.

Still testing.

FYI - From what I can tell, the EXTRAHD does not populate /etc/fstab so I am not sure what happens on a reboot.

The code scans for the UUID’s of all block devices and uses that data to mount all available drives on the previously defined mount points but if you want details you will need to go through the code.

I knew the old code pretty well but now its time to learn the new code! :exploding_head:

rebooting does not re-mount the external drive. And the external drive cannot be re-mounted via extrahd.

I can get the extrahd to mount a external drive by removing the needed drive from /var/ipfire/extrahd/devices. And then all is well until the next reboot.

I’ll add to bugzilla

this! very nice find!!

@ewald - please add this to bugzilla.

it is udev-event that is missing

A bug report has been issued:


atm it’s working again with build 180 testing.

1 Like