Sie sind nicht angemeldet.

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

1

12.01.2018, 16:05

./install.sh im Terminal klappt nicht: "Befehl nicht gefunden"

Wie kannn das sein?
Auf dem einen PC klappts auf diese Art einwandfrei, auf dem anderen nicht:

Quellcode

1
2
3
4
5
$ sudo ./install.sh
sudo: ./install.sh: Befehl nicht gefunden

$ dir
i386  Installer-fr.htm	Installer.htm  install.sh  noarch

Dieses "install.sh" sollte normalerweise eine grafisch geführte Geräte-Installation starten
Danke für jeden Hinweis oder Tip

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (13.01.2018, 00:35)


Beiträge: 768

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 10 / 4.15.0-3-amd64

  • Nachricht senden

2

12.01.2018, 17:28

Vielleicht ist die Partition, auf der der Installer liegt mit "noexec" gemounted. Wenn das so ist, kannst Du auf der Partition nichts "ausführen", aus Sicherheitsgründen.

Prüfe also die Mountoptionen deiner Partition. Dann halt entweder auf exec ändern, bzw. den Installer von einer anderen Partition aus aufrufen, wo das Ausführen erlaubt ist.
Linux ist wie eine Suppe! Je besser die Zutaten, desto größer der Geschmack! :)

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

3

12.01.2018, 17:58

Danke
"noexec" scheint allerdings nicht der Fall zu sein - jedenfalls liefert "mount" keinen entsprechenden Hinweis und zum anderen hats eh nur eine Partition auf diesem PC.

Systempflege bezüglich alter Kernel und Pakete habe ich - nach Wiki - ebenfalls bereits durchgeführt

Unerklärlich ist mir vor allem
"Befehl nicht gefunden",
weil die anzusprechende Datei ist ja offensichtlich vorhanden

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (12.01.2018, 20:37)


4

12.01.2018, 21:20

Wenn die Datei nicht ausführbar ist, ist es eben kein Befehl. Ergo wird dieser "Befehl" auch nicht gefunden. ;)

Zeig mal

Quellcode

1
ls -l install.sh
mir is wurscht

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

5

12.01.2018, 22:36

Wenn die Datei nicht ausführbar ist, ist es eben kein Befehl. Ergo wird dieser "Befehl" auch nicht gefunden. ;)

Klingt irgendwie logo


Zeig mal

Quellcode

1
ls -l install.sh


liefert

Quellcode

1
2
$ ls -l install.sh
-rwxrwxr-x 1 XXX XXX 84 Nov 21  2012 install.sh



Muss dazusagen dass ich die Datei nochmal dorthin kopiert habe weil ich befürchtete dass sie beschädigt sei.
Die Datei ist laut "Eigenschaften" als ausführbar markiert und im Terminal erscheint nun - neuerdings - "permission denied"

Zudem scheint sie auf eine tiefer liegende (subsub directory) liegende Datei zu referenzieren.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (12.01.2018, 22:42)


  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

6

13.01.2018, 00:34

Hat sich erledigt
War offenbar ein Problem mit der Rechtevergabe in irgendwelchen Unterordnern auf welche zugegriffen wird.

Danke für die Hilfestellungen!

  • »geobart« ist männlich

Beiträge: 78

Registrierungsdatum: 10.05.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: Cinnamon

Andere Betriebssysteme: Mint 18.2 Cinn. + LMDE2 Cinn

  • Nachricht senden

7

13.01.2018, 19:01

Quellcode

1
sudo ./install.sh
startet doch ein grafisches Installationsprogramm?
Das hätte vermutlich mit

Quellcode

1
gksudo./install.sh
gestartet werden müssen. Möglich, dass es dir die Rechte im Home verbogen hat.
Gibt

Quellcode

1
find ~ -user root -ls
nichts aus, ist es i.O.
Veni, vidi, wiki. :thumbup:

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

8

13.01.2018, 23:18

Quellcode

1
sudo ./install.sh
startet doch ein grafisches Installationsprogramm?

Ja
Für die Installation einens Drucker/ Scannertreiber für Samsunggeräte



Das hätte vermutlich mit

Quellcode

1
gksudo./install.sh
gestartet werden müssen.

Möglich wärs, keine Ahnung.
Hatte diese GeräteInstallation in einem eigenen Unterordner und diesen mit der grossen chmod Keule bearbeitet.
Dann gings auch mit

Quellcode

1
sudo./install.sh

Vielleicht nicht schön aber zumindest wars effektiv.


Möglich, dass es dir die Rechte im Home verbogen hat.
Gibt

Quellcode

1
find ~ -user root -ls
nichts aus, ist es i.O.

naja
die Ausgabe ist ellenlang - nur sagt mir das alles nix.
Dafür bin ich offenbar zu doof

9

13.01.2018, 23:39

die Ausgabe ist ellenlang
Somit das Gegenteil dessen, was geobart als "i.O." bezeichnete. Da sollte idealerweise gar keine Ausgabe kommen. Die "große chmod-Keule" bringt nur scheinbar Verbesserung. Am Ende steht irgendwann eine Neuinstallation an.
mir is wurscht

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

10

13.01.2018, 23:58

Könnte diese ellenlange Liste nicht auch auf anderes zurückzuführen sein?

Mir schien, dass wenn ich einen einzigen Unterordner (in Downloads) - eben jener mit dieser Installationsroutiene - ändere, nicht auch völlig andere Unterordner (zB in Dokumente) betroffen werden sollten.
Diese auftauchenden Unterorder in "Dokumente" (nur genau zwei von sehr vielen dort) sind möglicherweise aus anderen PCs einmal herüberkopiert worden.

Ich bin hierin - also bezüglich der Rechte- und Besitzvergaben im allgemeinen - offen gestanden ziemlich blank bzw blick da trotz mehrfachen Anläufen einfach nicht durch.

Der von mir per chmod bearbeitete Unterordner in Downloads scheint übrigens nicht auf

  • »geobart« ist männlich

Beiträge: 78

Registrierungsdatum: 10.05.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: Cinnamon

Andere Betriebssysteme: Mint 18.2 Cinn. + LMDE2 Cinn

  • Nachricht senden

11

14.01.2018, 00:33

Schaden tut die Keule jedenfalls nicht:

Quellcode

1
sudo chown -R -v $USER:$USER /home/$USER/
(so wie es da steht, nichts anpassen)
und reboot

Würde ich auf alle deiner Rechner und Installationen anwenden. :rolleyes: Dann gehören die Dateien im Home wieder dem User.

Siehe dir das https://wiki.ubuntuusers.de/sudo/ genau an und beachte es, um nicht Fredl's Pessimismus zu befriedigen. ;) :D
Veni, vidi, wiki. :thumbup:

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »geobart« (14.01.2018, 00:39)


  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

12

14.01.2018, 00:39

sagenhaft!

Und was war das eben für ein Zauber?

edit:
Muss ich das nun jedesmal machen, wenn ich einen Ordner oder eine Datei von einem PC zum anderen kopiere???
Und wie verhält es sich mit rüberkopierten Daten von Windoof ?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »nochamal« (14.01.2018, 00:45)


  • »geobart« ist männlich

Beiträge: 78

Registrierungsdatum: 10.05.2009

Derivat: anderes Ubuntu-Derivat

Architektur: 64-Bit PC

Desktop: Cinnamon

Andere Betriebssysteme: Mint 18.2 Cinn. + LMDE2 Cinn

  • Nachricht senden

13

14.01.2018, 00:52

Kannst du durchaus machen. Oder eben die Dateirechte von User auf User ändern.

Kopierst du per Stick, sollte der Fat32 haben. Auf Fat16/32 gehen die Rechte verloren und die Probleme damit auch.
Veni, vidi, wiki. :thumbup:

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

14

14.01.2018, 00:55

bedankt !
:)


Der Beitrag ist zu kurz. Der Beitrag muss mindestens 10 Zeichen lang sein und 5 Wörter enthalten

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

15

14.01.2018, 13:07

Ich habe das jetzt - nach der Bereinigung mittels "chown" - nochmal durchgespielt

Sowohl

Quellcode

1
gksudo ./install.sh

als auch

Quellcode

1
sudo ./install.sh


klappen genau gleich.
Der einzige - für mich erkennbare - Unterschied ist, dass "gksudo" das Passwort ausserhalb des Terminal abfragt.

Was gäbe es noch für Unterschiede?



Und noch eine Frage zu "chown" bitte:
Könnte ich dies auch auf einen einzigen Ordner begrenzen?
Dieser Geräteinstallationsordner mit dem ich die Probleme hatte wurde ja ursprünglich aus einem .tar.gz entpackt und ich kann ja - falls ich dieses weitergebe - nicht wissen, ob das auf einem andern PC ohne den "chown Zauber" klappen wird

Beiträge: 768

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 10 / 4.15.0-3-amd64

  • Nachricht senden

16

14.01.2018, 13:08

Und was war das eben für ein Zauber?



Das war kein Zauber. Du hast lediglich chown mit Root Rechten gestartet und deine gesamten Userdaten in /home/user rekursiv wieder an deinen User übergeben.
Das musstest Du machen, weil Du durch falsche Anwendung einige Dateien an root übergeben hast und das sollte innerhalb /home nicht sein.

Überprüfe in Zukunft genau, was für sudo Kommandos Du absetzt. Analysiere den Befehl genau was er macht, BEVOR Du auf Enter drückst.
Wenn Du etwas gewissenhafter mit sudo umgehst, sollte Dir dieser Fehler nicht mehr passieren.

Merke Dir: sudo ist kein Allheilmittel! Man wendet es nur an, wenn es zwingend erforderlich ist!


Nachtrag:

Zitat

Dieser Geräteinstallationsordner mit dem ich die Probleme hatte wurde ja ursprünglich aus einem .tar.gz entpackt


Vielleicht hast Du das tar.gz mit sudo entpackt, was dann ein Anwendungsfehler deinerseits wäre. Zum entpacken braucht man nämlich keine root Rechte.

Benutze root mit Sinn und Verstand und dann brauchst Du auch den "chown-Zauber" nicht.
Linux ist wie eine Suppe! Je besser die Zutaten, desto größer der Geschmack! :)

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

17

14.01.2018, 14:06


Zitat

Dieser Geräteinstallationsordner mit dem ich die Probleme hatte wurde ja ursprünglich aus einem .tar.gz entpackt


Vielleicht hast Du das tar.gz mit sudo entpackt, was dann ein Anwendungsfehler deinerseits wäre. Zum entpacken braucht man nämlich keine root Rechte.

Benutze root mit Sinn und Verstand und dann brauchst Du auch den "chown-Zauber" nicht.


Nein, aber trotzdem danke für den Hinweis!

Ein .tar.gz entpacke ich "ganz normal" in Nautilus.
Bin keineswegs heiss auf Befehlszeilenakrobatik
;)


Meine Frage hat auch darauf abgezielt ob die entpackten Daten dann immer gleich schon dem "Richtigen" gehören? Beim entpacken auf einem fremden PC also demjenigen dort :?:

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »nochamal« (14.01.2018, 14:12)


Beiträge: 768

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 10 / 4.15.0-3-amd64

  • Nachricht senden

18

14.01.2018, 14:22

Die Dateien gehören immer dem, der sie anlegt. In diesem Fall wird eine Datei heruntergeladen und gehört also dem User, unter dem die Browser-Session läuft.

Würdest Du zum Beispiel deinen Firefox mit sudo starten (mach das bloß nie), dann würden die Dateien mit root Eigentümer gespeichert, weil der ganze Browser mit root Rechten läuft.
Linux ist wie eine Suppe! Je besser die Zutaten, desto größer der Geschmack! :)

  • »nochamal« ist der Autor dieses Themas

Beiträge: 116

Registrierungsdatum: 18.08.2013

Derivat: Ubuntu

Version: Ubuntu 16.04 LTS - Xenial Xerus

Architektur: 64-Bit PC

Desktop: Unity

  • Nachricht senden

19

14.01.2018, 14:37

Die Dateien gehören immer dem, der sie anlegt. In diesem Fall wird eine Datei heruntergeladen und gehört also dem User, unter dem die Browser-Session läuft.


Ok, soweit so klar
mercie!

Beiträge: 768

Registrierungsdatum: 08.11.2015

Derivat: unbekannt

Version: gar kein Ubuntu

Architektur: 64-Bit PC

Desktop: LXDE

Andere Betriebssysteme: Debian 10 / 4.15.0-3-amd64

  • Nachricht senden

20

14.01.2018, 14:57

Noch was zum Thema sudo VS gksudo.

Im Grunde genommen nimmt man sudo für das Terminal und gksudo für grafische Anwendungen, die mit root Rechten laufen sollen. In den meisten Fällen kann man auch grafische Anwendungen mit sudo starten, ohne Probleme zu bekommen.

Es gibt aber Ausnahmefälle, wo es bei falscher Anwendung zu Problemen mit dem Programm kommt oder Du Dir deine Rechte verbiegst. Es ist nämlich so, dass Du bei sudo Root Rechte bekommst, aber mit der Konfiguration des Users.
Mit gksudo erhälst Du auch Rechte von Root, aber auch mit der Konfiguration von root.

Wenn Du also mit sudo eine entsprechend kritische Anwendung startest, kann es sein, dass die Anwendung fehlerhaft läuft und Du Dir bei Speichervorgängen die Rechte deines Users verbiegst. Du kannst also wie in diesem aktuellen Fall nicht
auf deine Daten zugreifen oder noch schlimmer Du übergibst die Dateien .Xauthority und .ICEauthority an root und kannst Dich dann als User nicht mehr am Anmeldebildschirm einloggen und landest in einer Login-Schleife.

Letzteres mit der Login-Schleife sieht man hier im Forum einmal die Woche. Dieser Anwendungsfehler scheint also sehr beliebt zu sein, weil viel root ja oft viel hilft! *lach*
Linux ist wie eine Suppe! Je besser die Zutaten, desto größer der Geschmack! :)