PDA

View Full Version : connectie via fstab maar geen schrijfrechten



PiSang99
08-Apr-2014, 12:12
Hallo allemaal,

Ik ben helemaal klaar met Windows en heb daarom besloten om Opensuse 13.1 op mijn pc te zetten. So far so good :). Natuurlijk wil ik het mezelf zo makkelijk mogelijk maken en dacht kom laat ik mijn NAS shares mounten in lokale mappen zodat ik niet telkes een terminal sessie hoeft te starten om dat handmatig te doen. Veel trial and error en..... Ik heb alle shares gemount echter mag ik alleen maar lezen en er niet naar schrijven. Wat heb je nu aan een centrale opslag als je er niks op mag zetten?? Hieronder de stappen die ik heb ondernomen:

In de homefolder van de huidige gebruiker een map Shares aangemaakt
In de map shares alle mappen gemaakt die benodigd zijn om de shares van de NAS te mounten
Op de map shares een chmod 777 (chmon 777 Shares) Ik kreeg geen foutmelding dus ben er vanuit gegaan dat ik nu volledige rechten op die lokale map heb
Voor de zekerheid deze actie ook uitgevoerd op alle submappen in de map Shares
Op de map shares een chown [usernaam] gedaan, wederom geen foutmelding dus aangenomen dat ook deze actie correct is
Voor de zekerheid deze actie ook uitgevoerd op alle submappen in de map Shares

het bestand /etc/fstab geopend en daar de volgende regels aan toegevoegd: (ik type er 1 maar behoudens de mapnamen zijn ze allen gelijk)

//[ipnummer naar NAS]/share /home/[usernaam]/Shares/[mapnaam] cifs usernaam=[usernaam],password=[password],sec=ntlm,iocharset=urf8 0 0

het fstab bestand gesaved en een sudo mount -a commando gegeven. Shares worden gemount maar zoals hierboven gezegd als alleen lezen waar ik verwacht door het opgeven van de usernaam en het wachtwoord (van de NAS) in de fstab ik toch wel de schrijfrechten ook zou moeten hebben. Ik zit al een paar dagen te struinen op internet maar wordt uit de grote hoeveelheid verschillende inzichten en meningen niet echt veel wijzer wat ik zou moeten doen om er voor te zorgen dat ik ook kan schrijven. 't Zal vast iets simpels zijn voor jullie experts maar voor een newbie zoals ik toch een lastige onderneming.

Bedant alvast voor jullie reactie.

mvg

PiSang

jansteen
09-Apr-2014, 00:38
Welkom!

ik moet eerlijk toegeven dat ik niet zoveel weet over deze materie.
Er zijn hier anderen die je wel kunnen helpen.
Wat je nog wel kunt doen is stoeien met de firewall (als je dat al niet gedaan hebt)
Zet die eens uit en kijk of er iets veranderd.
En anders even wachten op de echte experts ;)

PiSang99
09-Apr-2014, 02:18
Samba wordt door de firewall doorgelaten. Dat moet ook wel, anders zou ik de shares niet kunnen benaderen denk ik. Vanavond nog maar is verder spitten op internet......

PiSang99
09-Apr-2014, 12:25
Hmmmm, heb weer wat zitten vogelen vanavond...

Vanuit terminal een ls -l zegt me dat de user volledige rechten heeft op de folders in de map Shares. Een nieuwe map mag ik aanmaken maar daarna kan ik niets in de map plaatsen, 'k mag 'm daarna wel weer gewoon verwijderen. Eem tekstbestand mag ik niet aanmaken.
Wanneer ik nu vanuit Dolphin via netwerkbrowsing (wat overigens zo traag is dat je dat zelfs thuis niet zou willen) doe naar exact dezelfde lokatie op de NAS dan wordt ik eerst gepresenteerd met een scherm om mijn usernaam en wachtwoord in te geven....
...maar wacht eens... had ik dat al niet via fstab gedaan??? Zou dat dan niet gewoon overgenomen moeten worden???
enfin, na het ingeven van de usernaam en het wachtwoord mag ik gewoon alles doen wat ik wil, bestanden aanmaken, mappen aanmaken, bewerken, verwijderen, het maakt niet uit.

Conclusie: Wellicht moet ik nog ergens opgeven (buiten wat er in fstab staat) dat de user mag lezen en schrijven op de mappen die op de NAS staan.

Knurpht
10-Apr-2014, 07:43
Kun je die fstab regel 's hier posten tussen CODE tags (# in de editor). Uiteraard kun je de user en ww. door XXX vervangen, en het IP geloof ik ook wel.

Wat van belang is is of je de NAS username en ww hebt opgegeven.

Hieronder een werkende uit de praktijk:


//192.168.1.4/dir /mnt/dir cifs iocharset=iso8859-15,uid=1000,gid=100,rw,workgroup=WORKGROUP,noserverino,noperm,file_mode=0660,dir_mode=0770,user=xxxxxx,password=xxxxxxx 0 0

waarbij uid(1000=gebruiker) en gid(100=users) aangeven van welke linux gebruiker en groep de bestanden in de /mnt/dir zijn en de mappen en bestanden lees/schrijfbaar zijn voor eigenaar en groep. "user" en "password" zijn die van de Windows machine waarvan de share aangekoppeld is.

PiSang99
10-Apr-2014, 10:46
Hoi,

Usernaam en Wachtwoord zijn correct opgegeven. Deze user heeft ook voldoende rechten op de folders op de NAS

#//192.168.1.1/c/Documentation /home/admin/Shares/Documentation cifs username=xxxxxxxxxx,password=xxxxxxxxxx,sec=ntlm,iocharset=utf8 0 0#
#//192.168.1.1/c/media/Pictures /home/admin/Shares/Pictures cifs username=xxxxxxxxxx,password=xxxxxxxxxx,sec=ntlm,iocharset=utf8 0 0#
#//192.168.1.1/c/media/Music /home/admin/Shares/Music cifs username=xxxxxxxxxx,password=xxxxxxxxxx,sec=ntlm,iocharset=utf8 0 0#
#//192.168.1.1/c/media/Movies /home/admin/Shares/Movies cifs username=xxxxxxxxxx,password=xxxxxxxxxx,sec=ntlm,iocharset=utf8 0 0#
#//192.168.1.1/c/Software /home/admin/Shares/Software cifs username=xxxxxxxxxx,password=xxxxxxxxxx,sec=ntlm,iocharset=utf8 0 0#

Mountpoint acces:

drwxrwxrwx+ 7 admin nogroup 0 Apr 10 19:21 Documentation
drwxrwxrwx 2 admin users 4096 Apr 7 17:30 Movies
drwxrwxrwx 2 admin users 4096 Apr 7 17:30 Music
drwxrwxrwx 2 admin users 4096 Apr 7 17:30 Pictures
drwxrwxrwx 2 admin users 4096 Apr 7 21:06 Software

Ik zal die fstab regel van jou eens uitproberen.

PiSang99
10-Apr-2014, 11:01
Die regel van jou werkt, 'k heb het net even getest op 1 share en daar kan ik in elk geval schrijven als gebruiken. Bedankt voor je hulp lol!:good:lol!

PiSang99
10-Apr-2014, 11:29
Die regel van jou werkt, 'k heb het net even getest op 1 share en daar kan ik in elk geval schrijven als gebruiken. Bedankt voor je hulp lol!:good:lol!

Iets te vroeg gejuicht, na een reboot krijg ik een mount error 95

PiSang99
10-Apr-2014, 11:48
//192.168.x.y/c/Documentation /home/admin/Shares/Documentation cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Pictures /home/admin/Shares/Pictures cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Music /home/admin/Shares/Music cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Movies /home/admin/Shares/Movies cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/Software /home/admin/Shares/Software cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0

Na wat extra testen lijkt bovenstaande stabiel te blijven, ook na een reboot. het enige dat ik heb toegevoegd aan de al bestaande regels is dus de ,rw ,noperm en ,noserverinfo

Knurpht
10-Apr-2014, 12:16
//192.168.x.y/c/Documentation /home/admin/Shares/Documentation cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Pictures /home/admin/Shares/Pictures cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Music /home/admin/Shares/Music cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Movies /home/admin/Shares/Movies cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/Software /home/admin/Shares/Software cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0

Na wat extra testen lijkt bovenstaande stabiel te blijven, ook na een reboot. het enige dat ik heb toegevoegd aan de al bestaande regels is dus de ,rw ,noperm en ,noserverinfo

Mooi dat 't werkt. Ik gebruik die ouwe regel altijd omdat-ie zo mooi wat van beide kanten laat zien.

hws38
12-Apr-2014, 06:48
//192.168.x.y/c/Documentation /home/admin/Shares/Documentation cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Pictures /home/admin/Shares/Pictures cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Music /home/admin/Shares/Music cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/media/Movies /home/admin/Shares/Movies cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0
//192.168.x.y/c/Software /home/admin/Shares/Software cifs sec=ntlm,rw,iocharset=utf8,noserverino,noperm,username=username,password=password 0 0

Na wat extra testen lijkt bovenstaande stabiel te blijven, ook na een reboot. het enige dat ik heb toegevoegd aan de al bestaande regels is dus de ,rw ,noperm en ,noserverinfo

Even een vraagje van een niet-expert: ik lees "noserverino" in plaats van "noserverinfo". Een typefoutje, waarschijnlijk, of staat het echt zo in de fstab?

Knurpht
12-Apr-2014, 11:53
Even een vraagje van een niet-expert: ik lees "noserverino" in plaats van "noserverinfo". Een typefoutje, waarschijnlijk, of staat het echt zo in de fstab?

Uit
man mount.cifs komt dit stukje:



serverino
Use inode numbers (unique persistent file identifiers) returned by the server instead of automatically generating temporary inode numbers on
the client. Although server inode numbers make it easier to spot hardlinked files (as they will have the same inode numbers) and inode numbers
may be persistent (which is userful for some sofware), the server does not guarantee that the inode numbers are unique if multiple server side
mounts are exported under a single share (since inode numbers on the servers might not be unique if multiple filesystems are mounted under the
same shared higher level directory). Note that not all servers support returning server inode numbers, although those that support the CIFS
Unix Extensions, and Windows 2000 and later servers typically do support this (although not necessarily on every local server filesystem).
Parameter has no effect if the server lacks support for returning inode numbers or equivalent. This behavior is enabled by default.


noserverino
Client generates inode numbers itself rather than using the actual ones from the server.


See section INODE NUMBERS for more information.

hws38
13-Apr-2014, 00:54
Uit
man mount.cifs komt dit stukje:



serverino
Use inode numbers (unique persistent file identifiers) returned by the server instead of automatically generating temporary inode numbers on
the client. Although server inode numbers make it easier to spot hardlinked files (as they will have the same inode numbers) and inode numbers
may be persistent (which is userful for some sofware), the server does not guarantee that the inode numbers are unique if multiple server side
mounts are exported under a single share (since inode numbers on the servers might not be unique if multiple filesystems are mounted under the
same shared higher level directory). Note that not all servers support returning server inode numbers, although those that support the CIFS
Unix Extensions, and Windows 2000 and later servers typically do support this (although not necessarily on every local server filesystem).
Parameter has no effect if the server lacks support for returning inode numbers or equivalent. This behavior is enabled by default.


noserverino
Client generates inode numbers itself rather than using the actual ones from the server.


See section INODE NUMBERS for more information.



Dank ! Ik zou niet gauw (lees: nooit) op het "man cifs" idee gekomen zijn.
Wat is het soms toch gemakkelijk om te lezen wat je denkt dat er staat in plaats van wat er staat.