| 00:09.34 | ShadowJK | Actually I thought access controls were done on nfs client |
| 00:45.29 | DocScrutinizer05 | well, obviously not to the extent that it checks server's dir permissions and owner:group prior to sending a RPC |
| 00:46.40 | DocScrutinizer05 | I duuno the details since I never looked at the gory internal details of NFS, but the diagnostics are unambiguous |
| 00:46.58 | DocScrutinizer05 | see above |
| 00:47.30 | DocScrutinizer05 | s/duuno/dunno/ |
| 01:23.56 | *** join/#maemo-ssu sunny_s (~sunny_s@business-092-079-020-027.static.arcor-ip.net) |
| 02:01.59 | *** join/#maemo-ssu amiconn_ (amiconn@rockbox/developer/amiconn) |
| 02:07.25 | *** join/#maemo-ssu tg (~irc@2001:738:2001:2078:0:215:11:82) |
| 02:47.50 | *** join/#maemo-ssu tg (~irc@2001:738:2001:2078:0:215:11:82) |
| 02:59.43 | *** join/#maemo-ssu amiconn_ (quassel@rockbox/developer/amiconn) |
| 03:04.08 | *** join/#maemo-ssu DocScrutinizer05 (~HaleBopp@openmoko/engineers/joerg) |
| 03:05.09 | *** join/#maemo-ssu tg (~irc@2001:738:2001:2078:0:215:11:82) |
| 03:21.45 | *** join/#maemo-ssu Raimu-Z (~raimu@kameli.net) |
| 03:25.04 | *** join/#maemo-ssu tg (~irc@2001:738:2001:2078:0:215:11:82) |
| 04:39.48 | *** join/#maemo-ssu int_ua (~int_ua@ip-602f.proline.net.ua) |
| 06:19.43 | *** join/#maemo-ssu FReaper (~assassin@203.106.65.1) |
| 06:25.46 | *** join/#maemo-ssu M13 (~Miranda@83.149.37.177) |
| 06:48.32 | amiconn | didn't see the described nfs behaviour so far, but then didn't specifically test it either |
| 06:48.50 | amiconn | Maybe it depends on the nfs version in use? |
| 06:49.14 | *** join/#maemo-ssu freemangordon (~ivo@130-204-50-168.2074221835.ddns.cablebg.net) |
| 07:18.53 | *** join/#maemo-ssu kolp (~quassel@212.255.237.156) |
| 07:30.48 | *** join/#maemo-ssu dhbiker (~dhbiker@95.87.145.172) |
| 07:31.43 | *** join/#maemo-ssu Raimu (rmaunula@tuomi.oulu.fi) |
| 07:34.26 | *** join/#maemo-ssu M4rtinK (~M4rtinK@ip-86-49-81-87.net.upcbroadband.cz) |
| 07:40.18 | *** join/#maemo-ssu FlameReaper (~assassin@203.106.65.1) |
| 08:35.17 | *** join/#maemo-ssu Pali (~pali@Maemo/community/contributor/Pali) |
| 09:19.25 | *** join/#maemo-ssu futpib (~futpib@89.106.197.71) |
| 09:39.32 | *** join/#maemo-ssu futpib (~futpib@89.106.197.71) |
| 10:15.36 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 10:31.49 | *** join/#maemo-ssu futpib (~futpib@89.106.198.161) |
| 10:49.18 | DocScrutinizer05 | any additional input appreciated |
| 10:53.34 | DocScrutinizer05 | you just need a NFS mount with a dir that's 770 n:42(thegroup), and a user that has id UID=<x>(username ) group=<y>(somegroup) groups=...42(thegroup)... |
| 10:57.52 | DocScrutinizer05 | or: cd <nfs-mount>; mkdir xy; chown :4711 xy; chmod 770 xy; adduser -G 4711 testuser; su - testuser; cd <nfs-mount>; date >xy/xyz; echo "this will have failed"; sg 4711; date >xy/xyz; echo "this will have succeded" |
| 10:59.19 | DocScrutinizer05 | ^^^ no warranties, those commands are typed 2blindly" |
| 11:01.29 | *** join/#maemo-ssu futpib (~futpib@89.106.198.161) |
| 11:02.46 | amiconn | If group ids and user ids of server and client are in sync, permissions defined by secondary groups should work as long as the user is in no more than 16 groups |
| 11:03.34 | amiconn | If the user has more than 16 groups, the server should be started using the --manage-gids option, and then group membership on server and client must also match |
| 11:04.05 | amiconn | This option will make the server look up the user's group membership locally |
| 11:05.23 | DocScrutinizer05 | HEY! :-)) |
| 11:05.29 | DocScrutinizer05 | where from you got that? |
| 11:06.25 | amiconn | Teh incredible Google... |
| 11:06.33 | DocScrutinizer05 | it perfectly explains our situation, since our user/group id's are _not_ in sync |
| 11:06.58 | amiconn | E.g. here: https://xkyle.com/solving-the-nfs-16-group-limit-problem/ |
| 11:08.59 | DocScrutinizer05 | thanks a ton! |
| 11:52.25 | DocScrutinizer05 | https://xkyle.com/solving-the-nfs-16-group-limit-problem/comment-page-1/#comment-5294 is to the poibt |
| 11:52.32 | DocScrutinizer05 | point even |
| 11:56.32 | *** join/#maemo-ssu lizardo (lizardo@nat/indt/x-pmdxatiqhbytdffu) |
| 12:29.09 | *** join/#maemo-ssu futpib_ (~futpib@89.106.197.65) |
| 12:36.17 | *** join/#maemo-ssu LauRoman (~LauRoman@5-14-92-176.residential.rdsnet.ro) |
| 13:36.46 | *** join/#maemo-ssu Martix (~martix@eduroam-230.fi.muni.cz) |
| 13:38.00 | *** join/#maemo-ssu Martix_ (~martix@eduroam-230.fi.muni.cz) |
| 14:00.59 | *** join/#maemo-ssu DocScrutinizer51 (~lagrange@lagrange.cloud-7.de) |
| 14:18.21 | *** join/#maemo-ssu DocScrutinizer51 (~lagrange@openmoko/engineers/joerg) |
| 14:37.50 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 14:50.07 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 16:01.12 | *** join/#maemo-ssu NIN101 (~NIN@p5DD28B67.dip0.t-ipconnect.de) |
| 16:41.04 | *** join/#maemo-ssu tg (~irc@2001:738:2001:2078:0:215:11:82) |
| 16:56.47 | *** join/#maemo-ssu M13 (~MirandaLS@170.133-224-87.telenet.ru) |
| 16:57.15 | *** join/#maemo-ssu amiconn (amiconn@rockbox/developer/amiconn) |
| 16:59.45 | *** join/#maemo-ssu Vlad_on_the_road (~Vlad_on_t@ip-66.net-82-216-1.versailles2.rev.numericable.fr) |
| 17:06.55 | *** join/#maemo-ssu FlameReaper (~assassin@175.139.155.95) |
| 17:45.28 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 17:47.32 | *** join/#maemo-ssu discopig (~discopig@modemcable140.167-130-66.mc.videotron.ca) |
| 17:47.32 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 18:01.33 | *** part/#maemo-ssu freemangordon (~ivo@130-204-50-168.2074221835.ddns.cablebg.net) |
| 18:22.30 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 18:23.03 | *** join/#maemo-ssu nox- (noident@freebsd/developer/nox) |
| 18:25.19 | *** join/#maemo-ssu ruskie (ruskie@sourcemage/mage/ruskie) |
| 18:31.10 | *** join/#maemo-ssu luf (~luf@ip-94-112-59-161.net.upcbroadband.cz) |
| 18:33.49 | *** join/#maemo-ssu ruskie (ruskie@sourcemage/mage/ruskie) |
| 18:38.08 | luf | DocScrutinizer05: Maybe I miss something but nfs v4 with rpc.idmapd doesn't need to have same uids gids on client and server. |
| 18:41.23 | DocScrutinizer05 | luf: sorry, this is too fuzzy to help me out |
| 18:44.34 | DocScrutinizer05 | https://xkyle.com/solving-the-nfs-16-group-limit-problem/comment-page-1/#comment-5294 is describing exactly what we see on maemo infra. And removing the --manage-gids option should fix stuff for that system |
| 18:46.54 | luf | http://mg.pov.lt/maemo-ssu-irclog/latest.log.html#t2013-04-11T00:32:21 |
| 18:47.08 | luf | Ok maybe I understood it wrong way. |
| 18:48.17 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |
| 18:49.02 | DocScrutinizer05 | our IDs are not in sync on the NFS-linked mahines. Particularly on server side the groups are not defined as needed, so --manage-gids will make things fail for that configuration |
| 18:51.51 | DocScrutinizer05 | NB that we're NOT sufering from >16 groups problem, we're suffering exactly from contrary: our system worked _without_ --manage-gids, and the supposed "fix" introduced by recent --manage-gids as default makes things start to fall apart, since our UID/GID and etc/group config never been in sync on both machines |
| 19:02.56 | *** join/#maemo-ssu discopig (~discopig@2001:5c0:1000:a::11bd) |
| 19:02.56 | *** join/#maemo-ssu discopig (~discopig@unaffiliated/discopig) |
| 19:21.13 | *** join/#maemo-ssu M4rtinK (~M4rtinK@mail.melf.eu) |
| 19:39.07 | *** join/#maemo-ssu MohammadAG (~MohammadA@Maemo/community/contributor/MohammadAG) |
| 20:07.37 | *** join/#maemo-ssu Martix (~martix@static-84-242-103-180.net.upcbroadband.cz) |
| 20:29.07 | Pali | ~rescueos |
| 20:29.07 | infobot | extra, extra, read all about it, rescue-os is http://206.253.166.96/N900/rescueOS/ |
| 20:51.27 | *** join/#maemo-ssu freemangordon (~freemango@130-204-50-168.2074221835.ddns.cablebg.net) |
| 21:36.13 | *** join/#maemo-ssu arcean (~arcean@aafq163.neoplus.adsl.tpnet.pl) |
| 23:14.07 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |
| 23:43.38 | *** join/#maemo-ssu BCMM (~user@unaffiliated/bcmm) |