Worked like a charm. Thank you
How do we delete these udev rules?
Its a dirty solution but it works for me.
this worked for me for the samba-share add-on with my ext4 drive, but frigate shows 233gb(or so) in use when starting to use this drive, even though it was freshly formatted.
anyone else had this?
I couldn’t import from usb, so I created the file and edit it using ssh. I think it’s even simpler than using a usb stick.
That’s the 5% Linux always reserves when formatting ext4 for root.
You can set that to 0.
tune2fs -m 0 /dev/sdb1
ofcourse change /dev/sdb1 to your needs
Linux does this for all filesystems so that if you fill the drive completely full, there is still space to delete a file. WHAT? Well, when you delete a file, the directory (folder) needs to be written. If there is no free space, it could become impossible to rewrite the directory, which means that it is impossible to delete and there is no way back from that. So even with tunefs, it is best not to make the free space reserve completely zero.
1 Like
Good to know!
In my particular situation its a USB storage solely for CCTV data.
So if your aforementioned situation does occur, I don’t care if the drive needs to be formatted.
But Its maybe good practise to set it to 1 instead of 0. Especially for the large drives.
1 Like
This did´t worked for me, because after a HA reboot in most times the share was not available or locked and frigate took then again the HA root disk media share…
I have now created an additional Proxmox VM with OpenMediaVault and assiged my external USB-Connected SSD to a real SMB share unter OMV. This works rock solid now.
1 Like
I still have issues with NTFS HDD Drive. I see mounted folder inside the Media Folder. But I do not see any files.
Description of my drive
Subsystem:
block
Path to device:
/dev/sdb1
Identifier:
/dev/disk/by-id/ata-WDC_WD10SMZW-11Y0TS0_WD-WX21A87EUF46-part1
Attributes:
DEVLINKS: >-
/dev/disk/by-id/ata-WDC_WD10SMZW-11Y0TS0_WD-WX21A87EUF46-part1
/dev/disk/by-id/usb-WD_Elements_25A2_575832314138374555463436-0:0-part1
/dev/disk/by-id/wwn-0x50014ee6b29e95d8-part1 /dev/disk/by-label/Elements
/dev/disk/by-partlabel/Elements
/dev/disk/by-partuuid/9ba7f996-b7b7-4c6e-b65d-e7fafcd7e500
/dev/disk/by-path/pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0-part1
/dev/disk/by-uuid/EABC4987BC494EEF
DEVNAME: /dev/sdb1
DEVPATH: >-
/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0/host2/target2:0:0/2:0:0:0/block/sdb/sdb1
DEVTYPE: partition
DISKSEQ: '14'
ID_ATA: '1'
ID_ATA_DOWNLOAD_MICROCODE: '1'
ID_ATA_FEATURE_SET_APM: '1'
ID_ATA_FEATURE_SET_APM_CURRENT_VALUE: '128'
ID_ATA_FEATURE_SET_APM_ENABLED: '1'
ID_ATA_FEATURE_SET_PM: '1'
ID_ATA_FEATURE_SET_PM_ENABLED: '1'
ID_ATA_FEATURE_SET_PUIS: '1'
ID_ATA_FEATURE_SET_PUIS_ENABLED: '0'
ID_ATA_FEATURE_SET_SECURITY: '1'
ID_ATA_FEATURE_SET_SECURITY_ENABLED: '0'
ID_ATA_FEATURE_SET_SECURITY_ENHANCED_ERASE_UNIT_MIN: '180'
ID_ATA_FEATURE_SET_SECURITY_ERASE_UNIT_MIN: '180'
ID_ATA_FEATURE_SET_SMART: '1'
ID_ATA_FEATURE_SET_SMART_ENABLED: '1'
ID_ATA_ROTATION_RATE_RPM: '5400'
ID_ATA_SATA: '1'
ID_ATA_SATA_SIGNAL_RATE_GEN1: '1'
ID_ATA_SATA_SIGNAL_RATE_GEN2: '1'
ID_ATA_WRITE_CACHE: '1'
ID_ATA_WRITE_CACHE_ENABLED: '1'
ID_BUS: ata
ID_FS_BLOCK_SIZE: '512'
ID_FS_LABEL: Elements
ID_FS_LABEL_ENC: Elements
ID_FS_TYPE: ntfs
ID_FS_USAGE: filesystem
ID_FS_UUID: EABC4987BC494EEF
ID_FS_UUID_ENC: EABC4987BC494EEF
ID_MODEL: WDC_WD10SMZW-11Y0TS0
ID_MODEL_ENC: >-
WDC\x20WD10SMZW-11Y0TS0\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
ID_PART_ENTRY_DISK: '8:16'
ID_PART_ENTRY_NAME: Elements
ID_PART_ENTRY_NUMBER: '1'
ID_PART_ENTRY_OFFSET: '2048'
ID_PART_ENTRY_SCHEME: gpt
ID_PART_ENTRY_SIZE: '1953454080'
ID_PART_ENTRY_TYPE: ebd0a0a2-b9e5-4433-87c0-68b6b72699c7
ID_PART_ENTRY_UUID: 9ba7f996-b7b7-4c6e-b65d-e7fafcd7e500
ID_PART_TABLE_TYPE: gpt
ID_PART_TABLE_UUID: fb38a99b-7786-44d4-b7f6-90618b0f9282
ID_PATH: pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
ID_PATH_TAG: pci-0000_00_14_0-usb-0_2_1_0-scsi-0_0_0_0
ID_REVISION: 01.01A01
ID_SERIAL: WDC_WD10SMZW-11Y0TS0_WD-WX21A87EUF46
ID_SERIAL_SHORT: WD-WX21A87EUF46
ID_TYPE: disk
ID_USB_DRIVER: usb-storage
ID_USB_INSTANCE: '0:0'
ID_USB_INTERFACES: ':080650:'
ID_USB_INTERFACE_NUM: '00'
ID_USB_MODEL: Elements_25A2
ID_USB_MODEL_ENC: Elements\x2025A2\x20\x20\x20
ID_USB_MODEL_ID: 25a2
ID_USB_REVISION: '1019'
ID_USB_SERIAL: WD_Elements_25A2_575832314138374555463436-0:0
ID_USB_SERIAL_SHORT: '575832314138374555463436'
ID_USB_TYPE: disk
ID_USB_VENDOR: WD
ID_USB_VENDOR_ENC: WD\x20\x20\x20\x20\x20\x20
ID_USB_VENDOR_ID: '1058'
ID_WWN: '0x50014ee6b29e95d8'
ID_WWN_WITH_EXTENSION: '0x50014ee6b29e95d8'
MAJOR: '8'
MINOR: '17'
PARTN: '1'
PARTNAME: Elements
SUBSYSTEM: block
TAGS: ':systemd:'
USEC_INITIALIZED: '526491130'
dir_name: Elements
fstype: '-t ntfs3'
mount_point: /mnt/data/supervisor/media/Elements
No clue about NTFS mounts, my use case above was ext4.
I have moved since then from frigate addon to a frigate standalone server with its own storage. Made both installations much more stable, and no more weird mounting problems.
Dear All,
After installing HAOS 12.1 (or 12.2), I faced the following issue: after restarting the raspberry pi4 with the HAOS, it begins to bootloop. HAOS is installed on an ssd and a HDD is also connected to usb3 port (hdd case has external power supply). After a restart, the integrity check of the hdd starts, and after a few seconds it restarts, and so on…
If I disconnect the hdd, the HA can start without error and after a complete start I can connect the hdd again and it mounts automatically.
Do you experience the same and has a solution or this is a unique issue?
THX!
Is there any newer approach to (temporarily) access a locally (to the Raspberry Pi 4 where HA OS is running on) connected usb drive?
I just want to do some performance benchmarks and stress tests prior to moving from SD to this SSD (using hybrid mode).
Unfortunately in SSH even as root (checked with whoami) the mount command just gives:
mount: permission denied (are you root?)
Any ideas?
As mentioned it’s just for a temporary access and does not need to survive a host restart.
I’m trying to follow the steps descibed by paoloantinori, but I can’t succeed. I appreciate if someone can help with advice.
- I have HA running as OS on Raspberry Pi 5. OS version 13.2. Core 2024.10.3. Supervisor 2024.10.2.
- I have an external HDD, formatted as EXT4, plugged into the USB port of the RPi. This is what I’d like to automount under the Media folder.
- I have an USB stick, formatted as FAT32, labelled as CONFIG, plugged into the other USB port of the RPi. This holds the file 80-mount-usb-to-media-by-label.rules in a folder named udev. The file contains the ghist, as it is provided here, without any change.
- I have the Samba Share HA addon configured and can access the /homeassistant folder as an SMB share on my laptop running Win10.
Here’s what I tried so far:
- I’ve installed the “Advanced SSH & Web Terminal” and set an SSH password.
I can now SSH both from a terminal and from within the HA UI. - I’ve checked and found that the /etc folder did not contain the /udev subfolder.
- With the CONFIG stick plugged in I ran the SSH command “ha os import” (w/o quotes). This returned “Command completed successfully.” Then restarted HA.
This brought no joy. Nothing was mounted under Media and the /etc/udev folder still didn’t exist.
- I created the folder /etc/udev/rules.d/ through SSH.
- I plugged the CONFIG USB stick into my Win10 laptop, copied the 80-mount-usb-to-media-by-label.rules file into the media folder of the RPi via the SMB share.
- In SSH again, I moved the file from /media to /etc/udev/rules.d/
- Restarted HA again.
Still no joy. Nothing mounted under the media folder (nothing visible either in the HA UI under “My Media”, or in the /media/ folder in the SMB share / in SSH.
Thank you for any help!
I might be wrong, but I’m not sure if the SSH addon you have installed would allow you to peek into the correct /udev folder.
I suggest you to follow the procedure to activate ssh on the host to be sure.
See docs here:
Additionally: about the loading of the CONFIG formatted USB key, IIRC there was a hard-to-find shortcut somewhere in the UI to trigger it explicitly but I cannot find it right now
I’m running HA on RPI4 wih official image.
I’d like to use usb drive with ext4 fomat. it’s named STORAGE.
i don’t have /etc/udev folder
the system detects /dev/sda1 but i can’t mount to any mountpoint.
[core-ssh ~]$ mount /dev/sda1 /mnt/sda1
mount: mounting /dev/sda1 on /mnt/sda1 failed: Permission denied
I run homeassistant core in a python environment on Ubuntu. I successfully set up the udev rules and can access the mounted folders in the UI, however despite giving everything on the drive permissions, I still can’t seem to bypass the fact that I cannot have permission to read/write to the USB from the venv.
So I deleted the udev rules file in /etc/udev/rules, deleted everything in my media folder, removed the empty directories at the mount point… and still I cannot stop the previously mounted folders from appearing in the UI!! Does anyone know how to undo this??
I made an updated version of the code (a fork from the gist of eklex and the gist from zeehio:
It adds:
- An option to mount only partitions with a specific label
- An option to mount NTFS read/write as implemented by zeehio (uncomment that line only, if
modinfo ntfs3does not return an error) - ‘hassos-data’ partition won’t be mounted
- Some minor documentation
Successfully mounted external SSD storage (256 GB) using the udev method. However, it was only possible with an ext4-formatted partition. The mount persists after an HA restart.