Automount fra fstab fejler.

[poulb]

Hej
Jeg har et - synes jeg - lille dumt problem.
Tidligere var der i

Kode: Vælg alt

/etc/fstab

mulighed for automatisk at mounte netværksdrev under opstart. Ved hjælp at filen med cifs credentials kunne password lægges på f.eks

Kode: Vælg alt

/home/<navn>

Jvf denne linie i fstab...

Kode: Vælg alt

//192.168.1.5/htdocs   /media/htd    cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0

På et eller andet tidspunkt siden 14.04 blev mount-automatikken fjernet. Man måtte så omkring Ctrl+Alt+T
og kommandoen

Kode: Vælg alt

sudo mount -a

samt password for anden gang. Bevares ikke nogen væsentlig omvej, men alligevel irriterende. Er det tilsigtet eller en fejl?
For ikke selv at skulle skrive det hele ville jeg lægge en autostart i

Kode: Vælg alt

System -> Prefference -> Personel -> Startup applications

Men det er ikke lykkedes. Jeg forsøgte med...

Kode: Vælg alt

#!/bin/sh
# sudo /home/pba/Desktop/mount -a
# sudo mount -a , password=xxx

Jeg gør sikkert noget helt galt, men jeg kan ikke komme videre. Kommandoen virker i et terminalvindue. Men stadig med et ekstra password.

Noget bud?
vh
Poul

[AJenbo]

Det helt forkerte er nok at skrive adgangskodeden ind som en del af kommandoen, så bliver den tilgængelig i system over vågningen.
Kør istedet sæt istedet kommandoen (uden sudo) ind som en del af system opstarten

[poulb]

Det helt forkerte er nok at skrive adgangskodeden ind som en del af kommandoen, så bliver den tilgængelig i system over vågningen.

Ja! Det ved jeg, men i første omgang ville jeg blive glad hvis jeg kunne "automappe" i boot/login processen. FSTAB havde samme problem med pw i klartekst tidligere, men det blev løst elegant - synes jeg - ved at lægge bruger og password i en fil på eget område.

Kør istedet sæt istedet kommandoen (uden sudo) ind som en del af system opstarten

Det var det første jeg prøvede, men det giver ingen ændringer. Kun "sudo mount -a" eller den anden vej "sudo umount -a" fra terminal kan jeg få til at give det ønskede resultat.
Jeg har også uden succes prøvet at lave en "script" fil som f.eks kunne ligge på skrivebordet. "Mapning" ville da kunne opnås ved et enkelt museklik.
Venligst
Poul

[poulb]

Det helt forkerte er nok at skrive adgangskodeden ind som en del af kommandoen, så bliver den tilgængelig i system over vågningen.

Ja! Det ved jeg, men i første omgang ville jeg blive glad hvis jeg kunne "automappe" i boot/login processen. FSTAB havde samme problem med pw i klartekst tidligere, men det blev løst elegant - synes jeg - ved at lægge bruger og password i en fil på eget område.

Kør istedet sæt istedet kommandoen (uden sudo) ind som en del af system opstarten

Det var det første jeg prøvede, men det giver ingen ændringer. Kun "sudo mount -a" eller den anden vej "sudo umount -a" fra terminal kan jeg få til at give det ønskede resultat.
Jeg har også uden succes prøvet at lave en "script" fil som f.eks kunne ligge på skrivebordet. "Mapning" ville da kunne opnås ved et enkelt museklik.
Venligst
Poul

Hmmm... desværre er der intes som lykkes uńdtagen Ctrl+Alt+T med kommandoen "sudo mount -a"

Alt andet virker ikke. Hvorfor er en sådan funktionalitet fjernet ? Har heller ikke fundet noget (google) om årsagen. Automount er da ikke en ligegyldig facilitet... Hvad gør firmaer med en filserver ?

ØV

Poul

[zob]

Du har ikke nævnt det, men jeg gætter på at det er på din raspberry pi (raspian?). Hvis det er tilfældet og du har en fil der hedder

Kode: Vælg alt

/boot/cmdline.txt

så prøv at tilføj

Kode: Vælg alt

rootdelay=10

til enden af den fil. Hvis det virker så prøv at ændre 10 til 5, test igen, osv. Tag det laveste tal der virker for dig.

Hvis du ikke har den fil kan du prøve at tilføje dette kernelparameter til

Kode: Vælg alt

/etc/default/grub

, det kan jeg faktisk se jeg selv har gjort (eller er det sådan default?), ved hjælp af linjen:

Kode: Vælg alt

GRUB_CMDLINE_LINUX="rootdelay=10"

Forklaring:

Sometimes the OS can't distinguish a peripheral that's slow to respond from a peripheral that's not there or completely hosed. The most obvious example is a root filesystem coming from the network (TFTP, NFS) where a slow network link or an overloaded server are difficult to distinguish from a severed network link or a crashed server. A timeout tells the kernel when to give up.

This can also happen with disks that are slow to spin up, RAID arrays that need to be verified and so on. rootdelay instructs the kernel not to give up immediately if the device isn't available. The kernel can't know whether a SCSI drive is a local disk or some kind of RAID bay.

rootwait is provided to wait indefinitely. It's not always desirable, for example a system may want to fall back to a different root filesystem if the normal one takes too long to respond.

Kilde: http://unix.stackexchange.com/questions ... -rootdelay

[lath]

Hvis din init ikke er upstart, men i stedet er systemd, så skal det gøres anderledes.

Hvis din init er systemd, så skal du kort fortalt lave en systemd unit.
Du kan starte med at kigge på systemd.automount(5) manual siden:
http://www.dsm.fordham.edu/cgi-bin/man-cgi.pl?topic=systemd.automount&ampsect=5

Der er vigtigt at sørge for at det filsystem du mounter på allerede er mountet - med andre ord så er det meget vigtigt i hvilken rækkefølgen filsystemer bliver mounted.

Jeg har ikke arbejdet med systemd (endnu), så du er på egen hånd, da jeg ikke kan hjælpe dig mere end det her.
Måske nogen af de andre her i forum kan hjælpe dig.

Alternativt kan du installere pmount, og give dig selv tilladelse til at pmount et filsystem.
Derefter kan du uden at bruge sudo pmount et filsystem.

Du kan muligvis også bruge et FUSE filsystem.

Er block devicet med filsystemet du vil mounte altid tilkoblet din computer, så kan du putte din pmount/fusemount kommando ind i din session opstart.

Edit: det ser ud til at systemd kan bruge fstab(5), så der mangler nok en en form for konfiguration i din Ubuntu. Måske har du ikke genstartet computeren, så fstab ændringen ikke er slået igennem endnu.

/Lars

[poulb]

Du har ikke nævnt det, men jeg gætter på at det er på din raspberry pi (raspian?). Hvis det er tilfældet og du har en fil der hedder

Kode: Vælg alt

/boot/cmdline.txt

så prøv at tilføj

Kode: Vælg alt

rootdelay=10

til enden af den fil. Hvis det virker så prøv at ændre 10 til 5, test igen, osv. Tag det laveste tal der virker for dig.

Hvis du ikke har den fil kan du prøve at tilføje dette kernelparameter til

Kode: Vælg alt

/etc/default/grub

, det kan jeg faktisk se jeg selv har gjort (eller er det sådan default?), ved hjælp af linjen:

Kode: Vælg alt

GRUB_CMDLINE_LINUX="rootdelay=10"

Forklaring:

Sometimes the OS can't distinguish a peripheral that's slow to respond from a peripheral that's not there or completely hosed. The most obvious example is a root filesystem coming from the network (TFTP, NFS) where a slow network link or an overloaded server are difficult to distinguish from a severed network link or a crashed server. A timeout tells the kernel when to give up.

This can also happen with disks that are slow to spin up, RAID arrays that need to be verified and so on. rootdelay instructs the kernel not to give up immediately if the device isn't available. The kernel can't know whether a SCSI drive is a local disk or some kind of RAID bay.

rootwait is provided to wait indefinitely. It's not always desirable, for example a system may want to fall back to a different root filesystem if the normal one takes too long to respond.

Kilde: http://unix.stackexchange.com/questions ... -rootdelay

Nej det er ikke raspian pi. (kommer i test senere) Jeg kan godt følge tankegangen med lidt mere tid i opstarten, men ikke hvorfor denne ændring.

Opsætningen er helt ens i 2 stk lenovo B575e, en HP550 (lidt ældre sag) 2 stk desktop med MSI mbś og alle med 2 eller 4 GB RAM.

Kører jeg 14.04 -> 11.04 har jeg aldrig problemer. Kun når jeg booter med nyere end 1504... Har multiboot dvs 1 partion med 14.04 og en med f.eks 15.10 og en som jeg tester på. Mest på er en 16.04 beta1 eller daily builds.
Alle viser samme mønster.

"fstab" opsætningen er helt ens i alle maskiner... navn/password filen er /home/<navn>/smbc

Kode: Vælg alt

//192.168.1.5/media    /media/medi   cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0
//192.168.1.5/gene     /media/gene   cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0
//192.168.1.5/picture  /media/pic    cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0
//192.168.1.5/users    /media/user   cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0
//192.168.1.6/backup   /media/b1     cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0
//192.168.1.5/software /media/sw     cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0
//192.168.1.5/htdocs   /media/htd    cifs credentials=/home/pba/.smbc,iocharset=utf8,gid=1000,uid=1000,file_mode=0777,dir_mode=0777,sec=ntlm   0    0

Da jeg ikke på nogen måde - efter bedste viden - gør noget forskelligt mellen 14.04LTS og 15.10 og fremad er jeg helt på herrens mark.
vh
Poul

[AJenbo]

Der er nok blevet ændret lidt på hvordan man gør mellem Samba 4.1.9 og 4.1.17

[poulb]

Der er nok blevet ændret lidt på hvordan man gør mellem Samba 4.1.9 og 4.1.17

Er det et rent gæt eller noget du ved en lille smule om og burde indvie andre i ? Du får en til at lyde som et fjols...., Hvilket da er absolut muligt, men lidt dokumentation for det ville da værre dejligt - sådan mand og mand imellem. [ Lidt ironi og sårede følelser kan forekomme ovenfor ]

Jeg har selvfølgelig søgt rundt på nettet - men uden at finde noget som helst som skulle pege på en ændring i SAMBA.
https://wiki.samba.org/index.php/Mounting_samba_shares_from_a_unix_client

eller denne - som jeg har benyttet...
https://wiki.ubuntu.com/MountWindowsSharesPermanently eller
https://help.ubuntu.com/community/MountWindowsSharesPermanently

Den oplagte GOOGLE søgning.. https://www.google.dk/#q=how+to+mount+samba+drive giver en del hints og vejledninger - men intet som skulle indikere en så væsentlig ændring i Samba fra 15.xx og frem.

http://www.linuxnix.com/8-ways-to-mount-smbfs-samba-file-system-in-linux/
Denne vejledning kan jeg ikke replicere selv om jeg skriver som anvist. (her kan jeg lave fejl...)

Det der virkelig undre mig er, at der tilsyneladende ikke er andre der som jeg har brugt mulighederne i "permanent mount to network drives" Jeg har altid - som princip - valgt mindst muligt på den enkelte maskine og mest muligt på filserveren.

Venligst
Poul

[AJenbo]

Der skete store ændringer mellem 13.10 og 14.04 hvor der var mange der hade problemer med deres tidligere samba setup, det er blot ud fra det jeg gætter.

Du er ikke den eneste, følgende bug https://bugs.launchpad.net/ubuntu/+sour ... ug/1458100 peger på Systemd lige som lath henviste til. Prøv at starte med Upstart og se om det løser problemet.

Hvis du søger efter "samba fstab ubuntu 15.04" kommer der en del mere relevante resultater. Se om den her løser det:
http://askubuntu.com/questions/625715/u ... re-on-boot
(tilføj x-systemd.automount som et parameter i fstab linjen)