If you have a [Homes] section and use "valid users" on it and groups inside it, the CNID database cannot load and you get a temporary one.
Log shows this:
Aug 5 18:48:20 Server afpd[6695]: transmit: connecting to cnid_dbd ...
Aug 5 18:48:20 Server afpd[6695]: init_tsock: BEGIN. Opening volume '/home/jason', CNID Server: localhost/4700
Aug 5 18:48:20 Server cnid_metad[6687]: main: no volume for path "/home/jason"
Aug 5 18:48:20 Server afpd[6695]: write_vec: wrote 15 bytes
Aug 5 18:48:20 Server cnid_metad[6687]: main: request for volume: /home/jason
Aug 5 18:48:20 Server cnid_metad[6687]: load_volumes: BEGIN
Aug 5 18:48:20 Server cnid_metad[6687]: load_volumes: END
Aug 5 18:48:20 Server cnid_metad[6687]: getvolbypath("/home/jason")
Aug 5 18:48:20 Server cnid_metad[6687]: getvolbypath: user home section: 'Homes', basedir: '/home'
Aug 5 18:48:20 Server cnid_metad[6687]: getvolbypath: basedir regex: '/home', basedir match: "/home"
Aug 5 18:48:20 Server afpd[6695]: init_tsock: ok
Aug 5 18:48:20 Server cnid_metad[6687]: getvolbypath("/home/jason"): user: jason, homedir: /home/jason => volpath: "/home/jason/"
Aug 5 18:48:20 Server cnid_metad[6687]: createvol(volume: 'jason's home', path: "/home/jason/", preset: '-'): BEGIN
Aug 5 18:48:20 Server afpd[6695]: write_vec: wrote 48 bytes
Aug 5 18:48:20 Server afpd[6695]: send_packet: {done}
Aug 5 18:48:20 Server cnid_metad[6687]: createvol: END: 0
Aug 5 18:48:20 Server cnid_metad[6687]: main: no volume for path "/home/jason"
Aug 5 18:48:20 Server afpd[6695]: read: Connection reset by peer
Aug 5 18:48:20 Server afpd[6695]: read: Connection reset by peer
Aug 5 18:48:20 Server afpd[6695]: dbd_rpc: Error reading header from fd (db_dir /home/jason): Connection reset by peer
Eventually get a popup saying something wrong with the CDB using temporary.
Seems to be the cnid_metad is running as root.
cnid_metad during startup seems to load all volumes, and because obj->uid is 0 (root) in load_volumes() it means when createvol() is ultimately called it doesn't validate "valid users" etc because pwd is NULL.
However, when a request comes in for a Home directory, inside getvolbypath() it calls getpwnam(user), and then starts passing this through, so when it comes to validate "valid users" it actually does so. Problem is that in accessvol() it seems to check if the user has access based on the group the cnid_metad is running as, and not based on the passed in pw's groups.
So problem may be in accessvol()... but I'm not really clued up on all the other bits so can't say for sure if changed this will work correctly.
I can reproduce and second this with 3.0
I originally reported this issue.
Has this been fixed in recent revisions?
The original issue was with 3.0.0.
This may have been fixed for 3.0.3 with:
cc6053806460d7bccfc45ac85529bf696136aba6
Reload groups when reloading volumes
Reload the user groups every time the volume configuration changes
and also to call initgroups() again with the possibly changed groups.
FR #71
Changelog entry:
* UPD: Reload groups when reloading volumes. FR #71.
I probably won't get chance to check this though for a while. But I'll pop back when I do.
Just wrote a full explanation and SourceForge just dropped it into the ocean with a login prompt...
But yes its still an issue. It seems a missing set_groups() call in getvolbypath() that means that createvol receives an obj with uid set but with the groups for root user instead of those relevant to uid. I'm testing a patch to add this set_groups call
Still an issue in 3.1.6 that is
This patch works:
diff --git a/libatalk/util/netatalk_conf.c b/libatalk/util/netatalk_conf.c
index 16ade10..f79ea8a 100644
--- a/libatalk/util/netatalk_conf.c
+++ b/libatalk/util/netatalk_conf.c
@@ -1798,6 +1798,14 @@ struct vol getvolbypath(AFPObj obj, const char *path)
EC_NULL( realvolpath = realpath_safe(volpath) );
EC_NULL( pw = getpwnam(user) );
+
LOG(log_debug, logtype_afpd, "getvolbypath(\"%s\"): user: %s, homedir: %s => realvolpath: \"%s\"",
path, user, pw->pw_dir, realvolpath);
Filed as PR https://github.com/Netatalk/netatalk/pull/299
Merged.