Share mountas inte automatiskt med fstab vid start/omstart

Ska det inte vara //192.168.1.240/data enligt linuxstandard?

\\192.168.1.240\data /media/share cifs credentials=/root/.smb,users,rw,vers=2.0,iocharset=utf8

mount -a

Jag tippar på att det beror på att nätverket inte är tillgängligt ännu när den försöker mounta. Prova lägga till _netdev som option

Nej, cifs är kolumnen för typ av filsystem, _netdev ska i options-kolumnen. Såhär (glöm inte kommatecknet):

\\192.168.1.240\data /media/share cifs credentials=/root/.smb,users,rw,vers=2.0,iocharset=utf8,_netdev

I detta fall blir alltså svaret ja (se ovan), eftersom du inte verkar ha något i <dump> och <pass> - kolumnerna, vilket du inte heller behöver för nätverksdiskar (och knappt för några andra diskar heller nuförtiden).

För att förklara lite mer, fstab är organiserat i kolumner som separeras av ett eller flera mellanrum (mellanslag eller tab) mellan varje. Dessa är normalt rubrikerna (från min fstab på debian 11):

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

De kan vara lite svåra att överblicka eftersom formatet inte tar någon hänsyn till hur stora mellanrummen är, medan en editor som nano gör det. Så kolumnerna alignas för det mesta inte prydligt under varandra när du redigerar filen. Men räknar du antalet mellanrum (utan hänsyn till hur stora de är) så ser du snart hur kolumnerna är uppbyggda.

\\192.168.1.240\data /media/share cifs credentials=/root/.smb,users,rw,vers=2.0,iocharset=utf8,_netdev

# <file system> <mount point>   <type>  <options>       <dump>  <pass>

Japp, jag skrev fel, det är helt rätt som du skrev. Skyller på att jag var nyvaken och satt med mobilen

Tråkigt att det inte fungerade, det har hjälpt mig vid ett par tillfällen. Ett annat sätt att få det att fungera skulle kunna vara att använda x-systemd.automount, då ska den mounta först vid första gången du försöker komma åt utdelningen.

//192.168.1.240/data /media/share cifs x-systemd.automount,credentials=/root/.smb,users,rw,vers=2.0,iocharset=utf8

Jag använder följande:

IP:/path/data /mnt/data nfs defaults 0 0

Ok, jag har slut på idéer tyvärr. Googla på "systemd autmount network drive" och se om du kan hitta nåt passande script som löser det åt dig är nog mitt sista förslag.

Fast NFS är ett annat protokoll än vad som efterfrågas

Evt. måste något mer aktiveras för att systemd-automount ska fungera. Se högst rankade svaret här: https://askubuntu.com/questions/593174/x-systemd-automount-ci...

Om det funkar likadant med containers vet jag dock inte.

Körde du kommandot som tipsades om i felmeddelandet, journalctl -xe ? Isf vad säger det? Det bör vara ett gäng rader på slutet i det du får ut av kommandot, som beskriver lite mer om vad det var som gick fel.

Edit: det skriver ut en logg som fylls på med irrelevant text lite nu och då, så du behöver köra det direkt efter att systemctl osv. misslyckats.

\\192.168.1.240\data /media/share cifs credentials=/root/.smb,users,rw,vers=2.0,iocharset=utf8

mount -a

Misstänker att det är ett : som saknas.

# <file system>     <dir>       <type>   <options>   <dump>	<pass>
10.10.0.10:/backups /var/backups  nfs      defaults    0       0

https://linuxize.com/post/how-to-mount-an-nfs-share-in-linux/

Skulle dock rekommendera att du använder / och inte \ då jag vet att mount är ganska förlåtande för fel. Det är inte mount som monterar vid boot utan en demon. mount "städar" bara kommandoraden och kollar att du har rättigheter.

För en bättre felsökning skulle jag dessutom börja med defaults och sedan sätta in respektive option för att minska risken för andra fel. I 99% av fallen behövs inga extra kommandon. I så fall är något galet med rättigheterna. Gör om gör rätt. I Linux är rättigheter inte en subtraktion utan en addition. Du kan inte få färre rättigheter än du redan har. I så fall är du en annan identitet i proxmox.

Logiken här är att proxmox kan omöjligt veta vem du är när disken monteras före inloggning. Därför har du antingen en generell grupp som är disken alternativt en exklusiv användare som får använda disken. Det din dator berättar är just denna grupp eller användare.

När jag sätter upp en ramdisk lokalt så har jag en mapp med root-ägande och en ramdisk-grupp. Bara dom som är med i gruppen ramdisk kan använda mappen. Den här rättigheten sitter lokalt på den mapp som är ramdisken och har ingenting med uppgifter i /etc/fstab att göra.

Samma sak gäller för din nfs-mapp. Mappen på proxmox ska dom rättgiheter som proxmox ska bestämma. Din lokala mapp ska ha dom rättigheter ditt Linux-system ska tillåta.

Din identitet gentemot proxmox ska därför vara:

• öppen identitet (anonymus)

• Delad id-server (eller exakt samma namn / id på båda maskiner)

• exklusiv maskin(din dator)

• exklusiv användare på din dator

Delad id-server och exlusiv maskin är dom som är enklast att använda. Vanligtvis har du inte så hemlig info att du måste identifiera dig från din dator så länge den är identifierad hemifrån dig.

själv har jag samma id på alla maskiner, lätt att bara logga in med ssh och skyffla filer fram och tillbaka.

Prova detta:

Saxat från https://forums.raspberrypi.com/viewtopic.php?t=240974

//192.168.1.20/USB_Storage /srv/ReadyShare cifs username=XXXXX,password=yyyyyyyy 0 0

Or create /etc/systemd/srv-ReadyShare.mount

Requires=network-online.target
  After=network-online.service

[Mount]
  What=//192.168.1.20/USB_Storage
  Where=/srv/ReadyShare
  Options=username=XXXXX,password=yyyyyyyy,rw
  Type=cifs

[Install]
  WantedBy=multi-user.target