Oudepaginas‎ > ‎

Nas Perikelen

Nas beheren en configuren met Gigolo



Zie ComputerTip NAS x Gigolo
apt-get install samba gigolo fuse gvfs-backends
zie  mijn samba pagina voor wat je standaard moet installeren.
Ik vind gigolo niet zo handig

Remote access met nfs naar mn Nas werkt niet.



2016 1204 00:45
En nou heb ik m door. Nou snap ik waarom ik acl settings op mn shared directory's krijg op mn oude nas.
Als ik initieel een share maak, en die via nfs gebruik, dan werkt het. Er staan geen acl's op.
Als ik de nas vervolgens via samba benader, onder linux, door er met mn betstanden bladeraar door heen te bladeren, komen er acl's op.
Door via ssh met user root op de nas in te loggen, kan ik de acl van een directory verwijderen met serfacl -bR directory (nooit alleen een * gebruiken ivp directory)
Hoe kom je hier achterr ? Door in dezelfde terminal met getfacl directorie de rechten te vergelijken tussen een wel en niet benaderbare directory. Die verschillen zijn dan nogal vindbaar. Dus het ligt aan de acl's .
Plan : de oude nas niet meer gebruiken via Samba. Dit in de configuratie uitzetten. Mogelijk kan samba beter geconfigureerd worden. Maar mijn Nas moet mn linux backuppen. Dat kan zonder samba, en met nfs. En rsync.


https://forums.lenovo.com/t5/Iomega-Desktop-Network-Storage/Iomega-StorCenter-ix2-200-Cloud-Problem/td-p/1479180

https://forum.tele2.nl/randapparatuur-193/remote-access-naar-iomega-ix2-200-9987

https://www.gebruikershandleiding.com/Iomega-StorCenter-ix2-200/preview-handleiding-724698.html




Het regulier mounten, schrijfbaarzijn voor gewone users en backuppen met rsync zonder errors lijkt opgelost :-)

De tekst hieronder is niet geheel up to date. (Wat zeg je ? Geheel niet ? ook goed, vast wel >;-)
Tis ook maar een kladblok pagina

De hier onder beschreven sorus / zoekpuzzel is opgelost ... niet dus
Door Linux Mint 17.3 ging in de net werk setup de IPv6 aan.
Daardoor ??? blijkt mijn nas minder benaderbaar
Door mijn gezoek en geprobeer heb ik het probleem net jes gezegd : niet opgelost
Hoe de + bij de directory rechten van de nas mount partities is gekomen snap ik nog steeds niet.
Ik heb de nas weer braaf in orde, en ook vanuit windows is de nas weer keurig benaderbaar.
maar niet vanaf al mn pc's, en ook het rsyncen levert nog foutmeldingen op.

Onderstaande verhaal is opkladbok nivo. Maar ter lering en vermaak laat ik m nog even staan ...

Verhaal op de facebook group Linux Mint Nederland :

Nas mounten vanuit Linux Mint gaat niet zoals ik wil. Sinds 17.3 is er wat veranderd. Of ik heb wat vermeubeld. Zou kunnen. Kom er nog ff niet uit.
Hier mijn ervaringen impressie (vooral voor de meer dan gevorderden onder u) :
Gewone (niet de eerst aangemaakte) gebruikers krijgen er geen toegang op.
De eerste gebruiker heeft meer rechten dan elke volgende gebruiker. Die heeft meestal wel toegang.Hangt van de gebruikte pc af. Root mag er altijd op. Root werkt bij mij vanuit een terminal waarop ik met su - root ingelogd ben. Sudo is bij mij verboden. Ik ben in Unix groot geworden op SUN Solaris en dat is voor mij de standaard. Reguliere gebruikers en root. Geen mix.

Het advies om in /etc/passwd de UID's op pc en NAS aan elkaar gelijk te maken, leidt ook tot verrassingen in file rechten en eigenaarschap. Hier moet je verrekkes mee oppassen heb ik ervaren.
De overige gebruikers in de zelfde groepen zetten, als de eerste gebruiker in /etc/group maak ook het verschil niet : geen toegang in mn NAS.

Op mn NAS vanuit de terminal ingelogd met ssh, en daar /etc/passwd mn user IDs gelijk gemaakt aan die op mn pc. Waar ik de UID's dus ook gereorganiseerd heb. Zo ook de GID's in /etc/group. Wil je dit ook doen ? Weet dan dat als je UID's en GID's verandert, en je logt daarna in in een user met nieuwe UID en GID's, dan kom je er niet meer in. Erreurs ivm ontbrekend eigenaarschap. Jouw files zijn ineens zomaar van een andere user. Oplossing : CTRL ALT F1, log in met root. chown jouwuser.users terug. Je moet ook de -R optie gebruiken en ook de verborgen files meenemen. Opdelen in meerdere stappen en zorgen dat je alleen dingen verandert in je home directory's. En dat blijkt ook tricky. Kijk uit. Ik heb het weer voor elkaar.
Ik heb ook nog gekeken naar NAS:/etc/exports en PC:/etc/fstab, omdat daar de mount opties staan. Hier kun je een no_acl optie meegeven. Maar dat maakt niet uit, is mijn indruk.
Maar alles werkt nog, behalve de NAS toegang voor al mijn gebruikers.
En, sorry maar toch, onder windows 7 lukt het me ook niet meer om de NAS partities te openen. Drive mappen naar nas ip en share naam : kan niet gevonden worden
Vanuit het netwerk mn nas openen en inloggen lukt nog net, maar shares openen ho maar.

De NAS partities die ik gemount heb krijgen deze rechten : drwxrwx---+
De + duidt op het van toepassing zijn van ACL's. Ook daar heb ik al een mini studie op lopen.

Dus veel voer voor discussie.
Wat ik wil weten is :
1 hoe in de Ubuntu achtige linux versies, waaronder Mint, dat eerste gebruiker gedoe is geregeld. Zodat ik andere gebruikers die rechten ook kan geven.
2 Hoe zit het met die ACL's.
3 Welke goede raad heb je voor me ?

In ieder geval, van zo een exercitie leer je verrekkes veel.
Groetjes van Hans

Voor het mounten van ntfs partities vindt ik hierop een /etc/fstab voorbeeld regel :
UUID=526DBD82073E8323 /media/B1 ntfs defaults,nls=utf8,umask=000,uid=1000,windows_names 0 0

Voor mijn NAS Mount probleem vind ik deze opties voor pc:/etc/fstab heeel interessant : umask=000,uid=1000
Het geeft de indruk dat met de uid=nummer voor user hans, dat hans de shares daarmee weer zou kunnen gaan benaderen. Tis al laat, maar toch ff gauw proberen :
in /etc/passwd ben ik user 1001. user. 1000 is de eerst aangemaakte gebruiker. Die heet bij mij beheerder
pc:/etc/fstab regel :
nas:/nfs/public        /mnt/mijnnas/public        nfs    rw,user,sync,umask=000,uid=1001    0    0

alle mounts remounten kan met een commando, in mn root terminal :
mount -o remount *.
dacht ikl geeft een foutmelding met veel info. Das voor later

dit werkt gewoon
umount /mnt/mijnnas/*

als alle mount unmounted werden volstaat dit om ze weer te mounten:
mount -a
dacht ik. ook niet dus.

dus dan maar mounten met
mount /mnt/mijnnas/public
dat werkt

maar de nieuwe opties mogen niet ...


als root in de terminal gedaan (kijk nog ff verder eerst) :
setfacl -m "u:hans:rwx" public

en dan kan user hans weer op de share. Eindelijk opgelost ...
dacht ik. Niet dus. De subdirectories moeten ook nog van het slot af ...
Dat kan vast recursief met een optie -R. Jawel. Gelukking wel :

als root in de terminal gedaan, nu met -R toegevoegd :
setfacl -R -m "u:hans:rwx" public

zie man setfacl

Pfffff...

UITLEG


Een Nas is een "harddisk" in je netwerk. Met een netwerk kabel hang je m aan je router. En dan kun je er vanuit je pc verbinding mee maken en bestanden op zetten, ze bekijken, en wijzigen enzovoort.

Een NAS configureer je (uitleg volgt) ... en als het goed is, kun je de bestanden erop dan benaderen, vanuit zowel windows als vanuit Linux.
Daarvoor zijn verschillende protocollen

Ik heb twee Nas-sen.
En met beide heb ik zo wat problemen en uitdagingen.

Oja, dit verhaal is er een voor de verder gevorderde Linux gebruiker.

Tijdens het oplossen daarvan ben ik op zoek naar wijsheid op het internet. Hier een lijst met voor mijn puzzles blijkbaar nuttige sites :
https://en.wikipedia.org/wiki/Passwd
https://en.wikipedia.org/wiki/Group

https://help.ubuntu.com/community/FilePermissionsACLs
http://brunogirin.blogspot.com/2010/03/shared-folders-in-ubuntu-with-setgid.html

https://en.wikipedia.org/wiki/Setuid
http://nfs.sourceforge.net/nfs-howto/ar01s07.html#pemission_issues

de mount opties op de server uitgelegd : http://linux.die.net/man/5/exports


https://serverfault.com/questions/227852/what-does-a-mean-at-the-end-of-the-permissions-from-ls-l
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/ch-acls.html


Probleem 1 op mijn nas

Mijn pc's zijn allemaal ingericht met nfs (network file system) om onderling te kunnen netwerken.
Zulke verbindingen wil ik ook tussen pc en nas.
En dat kan en het werkt ook nog. Bijna ...

Het mounten van de nas partities met nfs in linux lukt met user root
maw root kan, in de terminal, de mount leggen
root kan dan ook lezen en schrijven op de gemounte nas partitie

vervolgens probeer ik als user hans op die partities te gaan kijken.
Dan krijg ik de foutmelding :


Hier de configuratie :

in pc_client:/etc/fstab :
mijnnas:/nfs/public    /mnt/mijnnas/public nfs rw,user,sync    0    0

in pc_client:/mnt/mijnnas zit de mount directory public
cd /mnt/mijnnas
ls -l public
drwxr-xr-x 2 root root 4096 jan 19 19:07 public

Omdat de nas aanstaat, het mounten is ingericht in /etc/fstab,
zal na opstarten de mount vanzelf gelegd worden.

Indien niet het geval (omdat je de config nog maar net gemaakt hebt bijvoorbeeld)
kun je nu ook (als user root) de mount leggen met :
mount /mnt/mijnnas/public

Heb je de zaken niet geregeld in /etc/fstab, dan kun je de mount leggen als user root met
mount mijnnas:/nfs/public /mnt/mijnnas/public -t nfs rw,user,sync

mount | grep -i nas
mijnnas:/nfs/public on /mnt/mijnnas/public type nfs (rw,user=root,noexec,nosuid,nodev,sync,addr=192.168.9.123)

cd /mnt/mijnnas; ls -l public
drwxrwx---+ 12 root users 4096 feb 14  2013 public

als user root
cd /mnt/mijnnas/public; ls -l
en zie daar de inhoud van deze partitie

als user hans
cd /mnt/mijnnas/public; ls -l
en zie daar de ... inhoud van deze partitie. Heeeee op deze flaptop doet ie het wel. Grijns. Dan is de config van mn NASzelf dus goed. Mooi zo.

Volgende keer meer, vanaf de andere pc, want daar gaat wat mis ... met deze nas mount

Nas uitdaging 2016 1124

Ja, het speelt weer / nog steeds.
Ik heb dus twee nassen.
Het verhaal hier direct boven is van toepassing.

User hans kan niet op de shares van de oudste :
hans:...nas2010>>cd linux/
ksh: cd: linux/: [Toegang geweigerd]

Beide nassen hebben een linux share.
De mount opties verschillen nogal.
Die komen als volgt in beeld :
mount | grep linux

nas2014:/volume1/linux on /mnt/nas2014/linux type nfs4 (rw,nosuid,nodev,noexec,relatime,sync,vers=4.0,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.1.12,local_lock=none,addr=192.168.1.214,user)

nas2010:/nfs/linux on /mnt/nas2010/linux type nfs (rw,nosuid,nodev,noexec,relatime,sync,vers=3,rsize=32768,wsize=32768,namlen=255,hard,noacl,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.1.201,mountvers=3,mountport=790,mountproto=udp,local_lock=none,addr=192.168.1.201,user)

En nu nog een keer, maar dan met de gelijkwaardie mount opties er uit gelaten

nas2014:/volume1/linux on /mnt/nas2014/linux type nfs4 (vers=4.0,rsize=131072,wsize=131072,port=0,clientaddr=192.168.1.12)

nas2010:/nfs/linux on /mnt/nas2010/linux type nfs (vers=3,rsize=32768,wsize=32768,noacl,mountaddr=192.168.1.201,mountvers=3,mountport=790,mountproto=udp,local_lock=none)

Interessant.
Dat wordt mount opties bestuderen
Te vinden in de terminal met
man mount

Volgende keer meer.


Tot zover : Nas uitdaging 2016 1124



############################################################
Hoe verwijder ik de ACL rechten, zodat
drwxrwx---+ 12 root users 4096 feb 14  2013 public
weer
drwxrwx---+ 12 root users 4096 feb 14  2013 public
wordt

ik dacht dat ik ze nodig had
heb de nas er op aangepast, acl's er op gezet. en nu wil ik er toch van af.
Want ACL's zijn er voor windows. En vanuit windows 7 kan ik niet meer mounten !!! Zie verderop.
met setfacl zet je ze er op
met getfacl kun je ze bekijken


Info op internet :

ACL commands : hoe gooi ik er er af. Staat het hier ?

https://wiki.archlinux.org/index.php/Access_Control_Lists




############################################################
Text created to post on forums, for support
Backup on NAS from Linux with rsync : Permission denied errors. Configuration support wanted.

I'm using Linux Mint with a kornshell script (based on my Unix SUN experience in the 90's :-) around rsync to backup on a Iomega Storcenter IX2-200 NAS. Script started manually by user hans, did work fine until recently... Perhaps it has something to do with the upgrade to Mint 17.3 ?
The mounts are configured in /etc/fstab, which just works.
Now when user hans tries to access the backup partition on the NAS, permission denied errors occurs. Same for the other partitions.
I already tried a lot of things. But except learning a lot, no progress yet ..

I hope someone can help me
Thanks in advance

Responce
from experience: check numerical user ids are the same.
Could be that your mint install has been assigned an IPV6 address; verify that this address has access to your Nas.

Hans
the IPV6 configuration was toggled ON by default and completely empty. I did turned it off. And now user hans has permission to access the NAS.


Hans :
aligning USER ID's in the /etc/passwd is tricky. I dont like it. Already tried both on NAS (by ssh in terminal) and on pc. Rescued myself on the pc by logging in as root with CTRL ALT F1, to chown all files and dirs in /home/hans back, to
make proper login possible ...

User ID of hans on NAS was 501. Changed to 1001. On pc it was ? 1000, I did changed it also to 1001. Will check at home at current situation.

What directory rights to give to the (unused, ie when unmounted) mount path ?
root.root, 777, or hans.users, 777 ?

Next issue in this story : ACL's. For some reason they showed up somewere in the recent history of this quest.  It starts with the mount path. When no NAS share is connected, the /mnt/mijnnas/myshare has a protection of drwxrwxrwx, owned by user hans in group lastname(I did create a group lastname>;-) When the NAS share is mounted, it turnes into drwxrwx---+, owned by user root in group users
Why ? And do I have to remove the ACL settings  ? With
setfacl ? And/Or change some config somewhere ?

Responce :

ACL is a Windows thing; in linux, you normally use 'chmod'.

If a filesystem is not mounted, you get to see the permissions of the mount point (directory). Once it's mounted, you get to see the permissions of the actual mounted filesystem. When not mounted, it would be best to block all r/w access for all users (chmod 000 /mnt/blah; chown root.root /mnt/blah) so that you don't accidentally put files there.

It's not clear from your description how you mount it. If you mount as NFS: sorry, you have to match the numeric UIDs. You can choose to enable 'squash_root' if you want local root to act as root on the NAS. Plain NFS is very insecure since there is no real authentication; any device with an IP address on your LAN can be configured to access all files that are exported via NFS. There are ways to secure NFS with Kerberos, but I never managed to make them work. I find it more practical to use the SMB protocol. That also removes the requirement of matching the UIDs.

As for your rsync issues: you need to provide more details: the output of 'mount' on both systems and the exact rsync command that you use. If relevant, also /etc/exports on the server.


Hans :
I already prepared matching UID's, but with two NAS's up and running ... With SSH I can login into the NAS terminal and change the UID info of involved users in nas1:/etc/passwd and in nas1:/etc/group, and also for nas2. And for laptop and pc I can match them too. On the PC's then I have to chown to new config. Is this save to do also in the NAS ? In NAS 1 I already did and now I cannot access it anymore from windows 7 >:-(..... I'm not happy to try this on nas2

Hans

In the weekend I managed to solve most issues. Because of the good remarks : IPv6 was toggled on since Mint 17.3, with all config empty. ACL = windows. Thank you. First by logging in with ssh into the nas, where I did removed all ACL's with setfacl -bR * in the shared directories. With that, my access from windows 7 came alive again. All relevant directories and files updated with chown -R root.users * and chmod -R 770 *. User and group id's on my pc's are almost matching. Challenge left is running rsync by user hans (with root it works !) with Nas mounted share over NFS, without errors like :
rsync: chgrp "/mnt/mijnnas/documenten/." failed: Operation not permitted (1)
Running rsync with root works without those error. I have to match group ID of hans on pc and nas. Tomorrow to be continued

Responce :
It is well possible that ACLs are exposed to Windows clients. You may be able to disable this "feature" via the server configuration. Alternatively, you can disable ACL at the filesystem level on the server (see my earlier post on 'tune2fs').
One way to find out is to check the file ctime stamp; ctime is the time when the file metadata (e.g. permissions) last changed; default is the 'mtime', the time when the file content last changed. To see the ctime stamp in linux: ls -l --time=c .

#####################################

 Summary uptil 2016 0216

IPv6 was toggled on since Mint 17.3, with all config empty. I did turn it off.

I did match the numeric UID's in /etc/passwd between 2 nasses and 3 pc's.
User hans listed in /etc/group as member of involved groups (bollen and users)

After changing configuration, I do reboot to be sure all  config is in place
(mmmm I have to reboot the NAS as well !?)

I did logged in with ssh terminal in my nas and deleted all ACL's
with setfacl -bR *
default protection in my nas for the share data :
drwxrwx---  and -rwxrwx---           (without acl)
drwxrwx---+ and -rwxrwx---+        (with acl)

NAS use in windows :
In windows 7 I can map one NAS share nfs:/muziek to a drive char  M:. I do need to login for access this share
In windows 7 I can login to the nas (under network), and then access all shares without mapping them indivually.

When accessing the nas from within windows 7, which prooved to fully work, the ACL's come back.
Which has inpact when accessing checking again from within Linux.

Within the whole quest, yesterday I managed to run my rsync script by user hans without ? errors once ?
Now access by user hans is not permitted again ?

I believe things depends on the weather conditions outside  >;-)

This looks good :
http://serverfault.com/questions/514118/mapping-uid-and-gid-of-local-user-to-the-mounted-nfs-share
typo on the page : nfs x  nfsd :
echo N > /sys/module/nfs/parameters/nfs4_disable_idmapping
echo N > /sys/module/nfsd/parameters/nfs4_disable_idmapping

The serverfault.com page does look very promissing. Great. I will try those advises
... which prooves more difficult than expected on first sight ...



######################################
aligning USER ID's in the /etc/passwd over nas and pc proved to be key ! I did and it was part of the finally found solution

rsync errors are gone too. I did closed my backup location by pointing rsync to a new directory.
So there it started with a new initial backup to make incrementals in for coming time.
Since there is no history here, no errors.
The new directory (owned by root, group users) I did make by logging into the nas with ssh in the terminal.
Then checked the ACL. It mentioned no access for any group. I did update this with setfacl.
Including all UID and GUI equal on pc and nas : it works again.
Still the question how ACL's get changed, while I was not aware of them since recently.
Probably because I do access the nas also from within windows 7 !?
Does that use the samba protocol ? Does it set acl's ? How to check this ?



######################################

hans:...hans>>cat /etc/fstab | grep documenten
mijnnas:/volume1/documenten    /mnt/mijnnas/documenten         nfs    rw,user,sync

hans:...hans>>cat /etc/mtab | grep documenten
mijnnas:/volume1/documenten /mnt/mijnnas/documenten nfs rw,noexec,nosuid,nodev,sync,vers=4,addr=192.168.1.214,clientaddr=192.168.1.12 0 0
hans:...hans>>

hans:...hans>>cd /mnt/mijnnas/
hans:...mijnnas>>ls -l documenten
totaal 96
drwxrwxrwx  4 root root 4096 feb 10 22:45 documenten


hans:...hans>>rsync -avn /home/hans/documenten/ /mnt/mijnnas/documenten/
sending incremental file list
./

sent 57 bytes  received 19 bytes  152.00 bytes/sec
total size is 0  speedup is 0.00 (DRY RUN)
hans:...hans>>
hans:...hans>>
hans:...hans>>
hans:...hans>>rsync -av /home/hans/documenten/ /mnt/mijnnas/documenten/
sending incremental file list
rsync: chgrp "/mnt/mijnnas/documenten/." failed: Operation not permitted (1)
./

sent 61 bytes  received 99 bytes  320.00 bytes/sec
total size is 0  speedup is 0.00
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1183) [sender=3.1.0]
hans:...hans>>
hans:...hans>>
hans:...hans>>




Comments