USB-Stick Mounten mit Init.d Script

  • 34 Antworten
  • Letztes Antwortdatum
S

Speedy8619

Neues Mitglied
0
Liebes Forum,
ich habe ein Problem und Finde nichts Passendes.

Ich habe ein Skript in /system/etc/init.d/ das beim Booten auch Ausgeführt wird, da der Ordner auch erstellt wird.

In dem Skript wird ein Ordner erstellt, und dann ein USB stick daran gemounted wird (/mnt/usb_drive1).

Nachdem aber Android 10 Fertig ist. ist der Stick wieder als /mnt/media_rw/ID gemounted. Ein erneutes ausführen des Skriptes, Hängt den USB stick wieder richtig ein. Ich möcht aber das der Stick gleich Passt nach dem Hochfahren. Ist ja auch der sinn von Init.d

Wie kann ich das am Besten veranlassen. Dachte auch an eine Schleife nur wie ich die am besten erstelle weiß ich nicht und ich weiß ja auch nicht ob das skript am Laufen bleibt.

LG Florian
 
@Speedy8619 Du musst das Script sehr, sehr spät ausführen, wie es scheint. Bei mir z.B. ist die Meldung, dass die SD-Karte gemountet ist, genau die Zeile über boot_complete:
[Thu Dec 10 22:22:35 2020] mmc1: card is UHS
[Thu Dec 10 22:22:35 2020] mmc1: selected SDR104
[Thu Dec 10 22:22:39 2020] init: processing action (sys.bootbroadcast_completed=*) from (/vendor/etc/init/hw/init.mmi.tcmd.rc:121)
Bei USB startet der Prozess zwar früher (mit der Bootanimation ungefähr), aber die Konfiguration dauert länger. Da tut sich also nicht viel.
 
Wie kann ich es nach Hinten verschieben?

Oder die Bootanimation Deaktivieren?
 
@Speedy8619 Du kannst das nicht einfach "nach hinten" schieben. Dazu müsste der ganze Bootprozess (init files) ab diesem Punkt geändert werden. Das sind ja alles Scripts (*.rc), die sich nacheinander ausführen und auch abhängig von Status des Bootprozesses sind.
Die Bootanimation spielt dabei keine Rolle, die habe ich nur zur Orientierung erwähnt. Das ist nämlich ungefähr der Punkt, ab dem frühstens eine ADB-Verbindung (USB) hergestellt werden kann.

Meiner Ansicht nach solltest du erst nach dem Bootprozess, also sobald der Stick vom System gemountet wurde, versuchen den Mountpoint zu ändern. Ich denke Tasker wäre eine bessere Lösung, weil du damit über den Bootprozess hinaus noch alle möglichen Ansätze hast. Zu diesem Zeitpunkt wird das System auch nicht mehr eingreifen und den Stick anders mounten.
 
Ok wollt nicht ne weitere APP installieren. WOllt eig. nur die eine FUnktion haben.
 
@Speedy8619 Dann mach entweder einen Symlink unter /mnt mit dem Namen "usb_drive1", der zu /mnt/media_rw/<USB STICK> führt oder versuch über "mount -bind" den bereits gemounteten Stick in deinem gewünschten Verzeichnis zugänglich zu machen. Ist im Prinzip ähnlich wie ein Symlink. So wird bspw. /sdcard eingebunden, deren realer Pfad eigentlich /storage/emulated/0 ist.
Beiträge automatisch zusammengeführt:

@Speedy8619 Im Script "init.rc" in der ramdisk werden doch genau diese Pfade unter /mnt erstellt. Entpack das boot.img und die darin enthaltene ramdisk und füg eine Zeile hinzu
Code:
symlink /mnt/media_rw/<USB STICK> /mnt/usb_drive1

Dann kannst über /mnt/usb_drive1 auf den Stick zugreifen, ohne ihn erneut zu mounten.
 
Zuletzt bearbeitet:
Solltest du Magisk installiert haben, ist die Sache noch viel einfacher. Erstell ein Script
#!/system/bin/sh
ln -s /mnt/media_rw/<USB STICK> /mnt/usb_drive1
und leg es unter /data/adb/service.d ab. Berechtigungen auf root:root und 0744. Fertig!

Bei jedem Neustart wird der Ordner als Symlink erstellt und du hast darüber vollen Zugriff auf den Stick.Der Befehl ln -s wird automatisch in der BusyBox von Magisk ausgeführt, da das Script unter /data/adb gespeichert ist.
Bei mir hat es wunderbar funktioniert. ;-)
 
ich bin ja eig. schon kurz vor dem Ziel nur er müsst ja das Script später starten oder Prüfen wie dieser Stick gemounted ist und dann ändern.

ich hab keine Zusätzliche App für sowas Auf dem Gerät.

Mit den Symlink erstellen hatte ich auch schon Probiert. allerdings war das Problem das ich nicht als User auf den Symlink komme. Ich weiß auch nicht wie ich die Berechtigung dafür ändern kann
 
@Speedy8619 Wofür brauchst du denn den Zugriff auf den Stick? Du hast Schreibrechte für /system, aber kein Magisk?
 
Speedy8619 schrieb:
allerdings war das Problem das ich nicht als User auf den Symlink komme.
Du kommst als User auch nicht auf /mnt/media_rw, das ist nicht das Problem. Der Zugriff für dich als User läuft nämlich über /storage.
Das Problem wird sein, dass bei einem manuell angelegten Mountpoint des Sticks alle Abhängigkeiten berücksichtigt werden müssen.

Das System, bzw. vold, erstellt zuerst ein weiteres Blockdevice unter /dev/block/vold/. Von dort aus wird er unter /mnt/media_rw als Dateisystem gemountet. Damit aber der Stick auch als Wechseldatenträger, bzw. Medienspeicher zur Verfügung steht, wird noch in /storage eingebunden. Damit kann Android ihn erst als Medienspeicher ansprechen.

Ich weiß nicht, inwiefern du welchen Zugriff darauf brauchst. Aber abgesehen davon, dass der Stick sich automatisch per Script nach Neustart nur schwer woanders mounten lässt, müssen auch die ganzen erforderlichen Zugriffe im System stimmen. Es wäre wesentlich einfacher, nicht gegen das System zu arbeiten, sondern mit dem System. Daher ist ein Symlink die sicherste und eleganteste Lösung.

Vielleicht kann der Symlink auch unter /storage angelegt werden??

Speedy8619 schrieb:
Ich weiß auch nicht wie ich die Berechtigung dafür ändern kann
Auch über die init-Scripte. Aber wie sollen sie geändert werden, ohne andere Zugriffe zu gefährden?? Was ist mit den SELinux-Kontexten?
Beiträge automatisch zusammengeführt:

Probier mal einen Symlink zu setzen, der unter /mnt/<STICK> angelegt wird und auf /storage/<STICK> verweist.

Bei mir habe ich als user0 vollen Zugriff über den Symlink auf die Karte, weil der Zugriff auch über /storage/<STICK> vorhanden ist.
 
Zuletzt bearbeitet:
also unter /storage/ befinden sich 2 Ordner.
emulated mit nichts drin
und self mit den Ordnern Primary -> Musik, Dokumente, ...

Im Init Skript ein
ln -s /dev/block/vold/public:8,0 /mnt/usb_share1 ergab beim Neustart scheinbar eine Verlinkung auf /dev/block/vold da ich dann den Eintrag public:8,0 sehe.

Kann es sein das es zum Zeitpunkt an dem Init.d ausgeführt wird Vold noch nicht gestartet wurde, und er auch gar erst nicht Mounten kann, und deshalb der Stick normal dann gemounted wird?
 
Speedy8619 schrieb:
also unter /storage/ befinden sich 2 Ordner.
Da habe ich nicht aufgepasst, denn das war nur meine SD-Karte.

Speedy8619 schrieb:
Im Init Skript ein
ln -s /dev/block/vold/public:8,0 /mnt/usb_share1 ergab beim Neustart scheinbar eine Verlinkung auf /dev/block/vold da ich dann den Eintrag public:8,0 sehe
Klar, der Symlink wird dich dorthin führen. Aber du hast dort keinen Zugriff, weil es unter /dev nur als Blockdevice und nicht als Dateisystem gemountet wird. Das Dateisystem befindet sich als tmpfs unter /mnt.

Speedy8619 schrieb:
Kann es sein das es zum Zeitpunkt an dem Init.d ausgeführt wird Vold noch nicht gestartet wurde
Wann dein Script genau startet und im Bezug dazu vold startet, kann ich nicht sagen. Im init.rc Script im Root-Verzeichnis steht es aber, wann vold gestartet wird. So wie ich das verstanden habe, ist es unmittelbar nachdem /data gemountet wurde.

Du kannst dir ein kernel.log (dmesg) und ein logcat.log direkt nach einem Neustart ansehen und es darüber nachvollziehen, wann was gestartet wird.

Die Frage ist immer noch, wofür du deinen Mountpoint brauchst? Denn der Zugriff ist im System normalerweise nur als root (owner) oder media_rw (group) gestattet. Jeder Zugriff erfolgt ja nur zwecks Medienabfrage. Du als user0 hast nirgends direkten Zugriff auf den Stick, sondern nur die Apps oder das System, um Medien für dich abzufragen.

Wie gesagt, der Symlink von /dev => /mnt bringt dir nichts. Das wäre der Weg den Stick zu mounten.
 

Demnach wenn ich es richtig Gelesen habe kann er die Platte nicht Mounten in dem Script weil er nicht weis was es ist. Und dann Kommt VOld und Mounted.

Aus dem Kleinen Ausschnitt

08-13 13:41:36.019 973 973 I init : type=1400 audit(0.0:129): avc: denied { execute } for name="91mnt" dev="mmcblk0p2" ino=81922 scontext=u:r:init:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
08-13 13:41:36.019 973 973 I init : type=1400 audit(0.0:130): avc: denied { execute_no_trans } for path="/system/etc/init.d/91mnt" dev="mmcblk0p2" ino=81922 scontext=u:r:init:s0 tcontext=u:object_r:unlabeled:s0 tclass=file permissive=1
08-13 13:41:36.052 908 908 I ntfs-3g : Unmounting /dev/block/vold/public:8,0 ()
08-13 13:41:36.072 154 154 D vold : /system/bin/sgdisk
08-13 13:41:36.072 154 154 D vold : --android-dump
08-13 13:41:36.072 154 154 D vold : /dev/block/vold/disk:8,0
08-13 13:41:36.079 977 977 I umount : type=1400 audit(0.0:131): avc: denied { search } for name="media_rw" dev="tmpfs" ino=9975 scontext=u:r:toolbox:s0 tcontext=u:object_r:mnt_media_rw_file:s0 tclass=dir permissive=1
08-13 13:41:36.091 154 154 D vold : DISK mbr
08-13 13:41:36.091 154 154 D vold :
08-13 13:41:36.092 154 154 W vold : disk:8,0 has unknown partition table; trying entire device
08-13 13:41:36.092 154 154 D vold : /system/bin/blkid
08-13 13:41:36.092 154 154 D vold : -c
08-13 13:41:36.092 154 154 D vold : /dev/null
08-13 13:41:36.093 154 154 D vold : -s
08-13 13:41:36.093 154 154 D vold : TYPE
08-13 13:41:36.093 154 154 D vold : -s
08-13 13:41:36.093 154 154 D vold : UUID
08-13 13:41:36.093 154 154 D vold : -s
08-13 13:41:36.093 154 154 D vold : LABEL
08-13 13:41:36.093 154 154 D vold : /dev/block/vold/disk:8,0
08-13 13:41:36.119 980 980 I mount : type=1400 audit(0.0:132): avc: denied { read } for name="filesystems" dev="proc" ino=4026532047 scontext=u:r:toolbox:s0 tcontext=u:object_r:proc_filesystems:s0 tclass=file permissive=1
08-13 13:41:36.119 980 980 I mount : type=1400 audit(0.0:133): avc: denied { open } for path="/proc/filesystems" dev="proc" ino=4026532047 scontext=u:r:toolbox:s0 tcontext=u:object_r:proc_filesystems:s0 tclass=file permissive=1
08-13 13:41:36.119 980 980 I mount : type=1400 audit(0.0:134): avc: denied { getattr } for path="/proc/filesystems" dev="proc" ino=4026532047 scontext=u:r:toolbox:s0 tcontext=u:object_r:proc_filesystems:s0 tclass=file permissive=1
08-13 13:41:36.119 980 980 I mount : type=1400 audit(0.0:135): avc: denied { mounton } for path="/mnt/test" dev="tmpfs" ino=8762 scontext=u:r:toolbox:s0 tcontext=u:object_r:tmpfs:s0 tclass=dir permissive=1
08-13 13:41:36.133 952 952 I AlarmClock: AlarmInitReceiver android.intent.action.LOCKED_BOOT_COMPLETED
08-13 13:41:36.141 952 982 I AlarmClock: Fixing alarm instances
08-13 13:41:36.156 154 154 D vold : /dev/block/vold/disk:8,0: UUID="3E58C9AC731297A9" TYPE="ntfs"
08-13 13:41:36.156 154 154 D vold :
08-13 13:41:36.162 154 154 D vold : Waiting for FUSE to spin up...
08-13 13:41:36.169 983 983 I bootstat: Service started: /system/bin/bootstat --record_boot_complete --record_boot_reason --record_time_since_factory_reset -l
08-13 13:41:36.169 983 983 E bootstat: Failed to read /data/misc/bootstat/post_decrypt_time_elapsed: No such file or directory
08-13 13:41:36.169 952 982 V AlarmClock: AlarmInitReceiver finished
08-13 13:41:36.169 983 983 E bootstat: Failed to parse boot time record: /data/misc/bootstat/post_decrypt_time_elapsed
08-13 13:41:36.190 984 984 W sdcard : Device explicitly enabled sdcardfs
08-13 13:41:36.196 203 203 D Zygote : Forked child process 986
08-13 13:41:36.201 383 412 I ActivityManager: Start proc 986:com.google.android.gms.persistent/u0a61 for broadcast {com.google.android.gms/com.google.android.gms.chimera.GmsIntentOperationService$PersistentTrustedReceiver}
08-13 13:41:36.213 154 154 D vold : /system/bin/blkid
08-13 13:41:36.213 154 154 D vold : -c
08-13 13:41:36.213 154 154 D vold : /dev/null
08-13 13:41:36.213 154 154 D vold : -s
08-13 13:41:36.213 154 154 D vold : TYPE
08-13 13:41:36.213 154 154 D vold : -s
08-13 13:41:36.213 154 154 D vold : UUID
08-13 13:41:36.213 154 154 D vold : -s
08-13 13:41:36.213 154 154 D vold : LABEL
08-13 13:41:36.213 154 154 D vold : /dev/block/vold/public:8,0
08-13 13:41:36.237 154 154 D vold : /dev/block/vold/public:8,0: UUID="3E58C9AC731297A9" TYPE="ntfs"
08-13 13:41:36.237 154 154 D vold :
08-13 13:41:36.239 993 993 I fsck.ntfs: type=1400 audit(0.0:136): avc: denied { getattr } for path="/data/media" dev="mmcblk0p4" ino=131118 scontext=u:r:fsck_untrusted:s0 tcontext=u:object_r:media_rw_data_file:s0 tclass=dir permissive=1
08-13 13:41:36.239 154 154 D vold : /system/bin/fsck.ntfs
08-13 13:41:36.239 154 154 D vold : -n
08-13 13:41:36.239 154 154 D vold : /dev/block/vold/public:8,0
08-13 13:41:36.249 993 993 I fsck.ntfs: type=1400 audit(0.0:137): avc: denied { ioctl } for path="/dev/block/vold/public:8,0" dev="tmpfs" ino=21176 ioctlcmd=0x1271 scontext=u:r:fsck_untrusted:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=1
08-13 13:41:36.265 154 154 D vold : Mounting volume... OK
08-13 13:41:36.265 154 154 D vold :
08-13 13:41:36.266 154 154 D vold : Processing of $MFT and $MFTMirr completed successfully.
08-13 13:41:36.266 154 154 D vold :
08-13 13:41:36.272 154 154 D vold : Checking the alternate boot sector... OK
08-13 13:41:36.272 154 154 D vold :
08-13 13:41:36.272 154 154 D vold : NTFS volume version is 3.1.
08-13 13:41:36.272 154 154 D vold :
08-13 13:41:36.272 154 154 D vold : NTFS partition /dev/block/vold/public:8,0 was processed successfully.
08-13 13:41:36.272 154 154 D vold :
08-13 13:41:36.273 154 154 I vold : Check OK
08-13 13:41:36.273 154 154 D vold : /system/bin/mount.ntfs
08-13 13:41:36.273 154 154 D vold : -o
08-13 13:41:36.273 154 154 D vold : utf8,uid=1023,gid=1023,fmask=7,dmask=7,shortname=mixed,nodev,nosuid,dirsync,noatime,noexec
08-13 13:41:36.273 154 154 D vold : /dev/block/vold/public:8,0
08-13 13:41:36.273 154 154 D vold : /mnt/media_rw/3E58C9AC731297A9
08-13 13:41:36.279 994 994 I mount.ntfs: type=1400 audit(0.0:138): avc: denied { getattr } for path="/dev/block/mmcblk0p2" dev="tmpfs" ino=9836 scontext=u:r:vold:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=1
08-13 13:41:36.279 994 994 I mount.ntfs: type=1400 audit(0.0:139): avc: denied { getattr } for path="/dev/block/mmcblk0p1" dev="tmpfs" ino=9783 scontext=u:r:vold:s0 tcontext=u:object_r:boot_block_device:s0 tclass=blk_file permissive=1
08-13 13:41:36.279 994 994 I mount.ntfs: type=1400 audit(0.0:140): avc: denied { ioctl } for path="/dev/block/vold/public:8,0" dev="tmpfs" ino=21176 ioctlcmd=0x125e scontext=u:r:vold:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=1
08-13 13:41:36.279 994 994 I mount.ntfs: type=1400 audit(0.0:141): avc: denied { ioctl } for path="/dev/block/vold/public:8,0" dev="tmpfs" ino=21176 ioctlcmd=0x1271 scontext=u:r:vold:s0 tcontext=u:object_r:vold_device:s0 tclass=blk_file permissive=1
08-13 13:41:36.279 986 986 I main : type=1400 audit(0.0:142): avc: denied { write } for name="tasks" dev="tmpfs" ino=10665 scontext=u:r:zygote:s0 tcontext=u:object_r:device:s0 tclass=file permissive=1
08-13 13:41:36.279 986 986 I main : type=1400 audit(0.0:143): avc: denied { open } for path="/dev/stune/foreground/tasks" dev="tmpfs" ino=10665 scontext=u:r:zygote:s0 tcontext=u:object_r:device:s0 tclass=file permissive=1
08-13 13:41:36.297 986 986 I Zygote : seccomp disabled by setenforce 0
08-13 13:41:36.323 1008 1008 I ntfs-3g : Version 2017.3.23 integrated FUSE 27
08-13 13:41:36.323 1008 1008 I ntfs-3g : Mounted /dev/block/vold/public:8,0 (Read-Write, label "", NTFS 3.1)
08-13 13:41:36.323 1008 1008 I ntfs-3g : Cmdline options: utf8,uid=1023,gid=1023,fmask=7,dmask=7,shortname=mixed,nodev,nosuid,dirsync,noatime,noexec

Das ganze Benötige ich für eine App. Diese durchsucht /mnt/usb_share1 ... Ich habe auch andere Ordner Versucht und festgestellt das die Rechte nicht passen. Bzw. er nicht lesen kann. Bis ich den ordner usb_share1 verwendete.
 
@Speedy8619 Wenn du Logs hast, lade sie einfach als .txt-Datei hier hoch. Das komplette Logcat ist schon nicht mehr abrufbar.
 
Ok ich dachte über Pastebin sei es gut
bzw. ich wüsste nicht was Fehlt
 
Zuletzt bearbeitet:
@Speedy8619 Wie sind die SE-Kontexte deines init-Scripts gesetzt? Laut den ersten Zeilen des kleinen Ausschnitts sind sie u:object_r:unlabeled:s0
Beiträge automatisch zusammengeführt:

Und schreib bitte mal,
- welches Android/Gerät du benutzt
- wie du auf /system zugreifst ohne Magisk (via TWRP?)
 
Zuletzt bearbeitet:
Oh ganz vergessen, Ich nutze den Rasperry PI und darauf Läuft ein Lineage OS das Android 10 ist.
Ich Nimm die SD karte aus den Raspberry und steck ihn in meinen Ubuntu PC und greife dann auf die Partition zu.
Beiträge automatisch zusammengeführt:

die Datei aus /system/etc/init.d/

C++:
#!/system/bin/sh
#
# Mount USB-Stick
mkdir /mnt/test
umount /mnt/media_rw/3E58C9AC731297A9

mount /dev/block/vold/public:8,0 /mnt/usb_share1

#ln -s /mnt/media_rw/3E58C9AC731297A9 /mnt/usb_share1
 
Zuletzt bearbeitet:
@Speedy8619 Kennst du dich mit den Zugriffsberechtigungen bei Linux aus? Sagen dir owner/group und rwx was?

Womit greifst du auf /system zu? Wie hast du dein Script in /system/etc kopiert?
 
Zuletzt bearbeitet:
Ich öffne dort mein Terminal und tippe

Code:
sudo nano _/system/etc/init.d/91mnt

Ja Die zugriffsberechtigungen sagen mir etwas das ich mittels
Code:
 sudo chown system:system dingsda
den Besitzer und die Gruppe bestimme und mit
Code:
 sudo chmod 764 dingsda
der Eigentümer Lesen, Schreiben, Ausführen darf. Die Gruppe lesen und Schreiben und alle andern nur Lesen
 
@Speedy8619 Welche Zugriffsrechte hat /mnt/usb_share1?

Wenn im Terminal ein Ordner erstellt wird, richtet sich das nach
- welcher User angemeldet ist in der Shell (bei sudo wird es root sein => root:root)
- umask: Standard ist 022, was von 777 abgezogen werden muss => 755 (-rwxr-xr-x)

Solltest du nichts geändert haben, ist dein Mountpoint mit diesen Zugriffsrechten vorhanden. Du brauchst aber für den Zugriff auf den Stick root:media_rw und 750 (steht im init.rc-Script)

Was noch hinzukommt ist, dass du nicht einfach den Befehl mount ohne weitere Optionen nutzen kannst. Damit werden keine Schreibrechte, kein Dateisystem (z.B. ext4, exFAT etc.) oder sonstige Optionen definiert (s. mount).

Mein USB-Stick als Beispiel:
Code:
:/ # mount | grep media_rw
/dev/block/vold/public:8,1 on /mnt/media_rw/28E9-33C5 type exfat
(rw,dirsync,nosuid,nodev,noexec,noatime,uid=1023,gid=1023,fmask=0007,dmask=0007,allow_utime=0020,namecase=0,errors=remount-ro)
Natürlich reicht auch die Definition von grundlegenden Angaben. Aber die müssen stimmen!

Nochmal zu dem Symlink: Der Symlink an sich wird immer mit 777 erstellt und ist für alle zugänglich. Nur die Zugriffsrechte des Ziels werden eingehalten. Somit kann deine App keine Zugriffsprobleme bekommen, wenn du einen Symlink setzt. Du als user0 schon, aber nicht die App.
 
Zuletzt bearbeitet:

Ähnliche Themen

tunsies
Antworten
3
Aufrufe
856
tunsies
tunsies
Brantgaard
Antworten
9
Aufrufe
730
Nightly
Nightly
M
Antworten
1
Aufrufe
350
Klaus986
K
Zurück
Oben Unten