My AFP / CNID DB issue that i can't solve...

[pierrep]

Hi gcooper,

i thought i should not pollute the 8.0.3 near-release announcement post so i'll continue here.
The command you requested returned nothing (no .AppleDesktop file or directory in my dataset)
This is probably because the root directory of the dataset is not writable to the user that's accessing it which is the default setting since 8.0-R and i did not change anything there.
Plus i like it like that, it allows me to control the first level directories so that users do not clutter said directory.

So i tried to create a new dataset from scratch and sharing it, like i did in 8.0-R
Here's the log :

#create dataset test from GUI
[pierre@freenas /mnt/pool/test]$ ls -la
total 3
drwxr-xr-x 2 root wheel 2 Dec 13 00:20 .
drwxr-xr-x 9 root wheel 9 Dec 13 00:20 ..
#su root
[root@freenas] /mnt/pool/test# mkdir toto
[root@freenas] /mnt/pool/test# chown pierre:users toto
[root@freenas] /mnt/pool/test# chmod g+w toto/
# from GUI, create AFP share test_share on test dataset, with R/W access for group users and DiskDiscovery (nothing else changed from default values)
# connecting to test_share as pierre (pierre:users) -- OK
# trying to copy a file to test_share -->>>> NOK CNID DB error message +log messages (see below)

Dec 13 00:25:45 freenas freenas[1743]: Executing: /bin/pgrep -F /var/run/afpd.pid afpd
Dec 13 00:25:46 freenas freenas[1743]: Executing: /bin/pgrep -F /var/run/afpd.pid afpd
Dec 13 00:25:49 freenas afpd[11839]: bind(fd, (struct sockaddr *)&address, address_length) failed: Address already in use
Dec 13 00:26:55 freenas afpd[11906]: AFP3.3 Login by nobody
Dec 13 00:26:57 freenas afpd[11906]: AFP logout by nobody
Dec 13 00:26:57 freenas afpd[11906]: dsi_stream_read: len:0, unexpected EOF
Dec 13 00:26:57 freenas afpd[11906]: afp_over_dsi: client logged out, terminating DSI session
Dec 13 00:26:57 freenas afpd[11906]: AFP statistics: 0.29 KB read, 0.28 KB written
Dec 13 00:27:04 freenas afpd[11933]: AFP3.3 Login by pierre
Dec 13 00:28:01 freenas cnid_metad[11837]: allocvolinfo("/mnt/pool/test"): No such file or directory
Dec 13 00:28:22 freenas last message repeated 22 times
Dec 13 00:28:22 freenas afpd[11933]: transmit: Request to dbd daemon (db_dir /mnt/pool/test) timed out.
Dec 13 00:28:22 freenas afpd[11933]: Reopen volume /mnt/pool/test using in memory temporary CNID DB.

So... should i *really* put the first level directory writable to the "users" group (or world) for AFP to work properly ?
This was apparently not the case in 8.0-R (as i mentioned already a few times and this would allow them to create whatever they want at first level.

I do not really have a lot of time to retest this with 8.0-R to make sure that what i'm saying is actually true in that version, but that's how i remember it.

If you have any idea on how to achieve what i want, i'd be glad.
Should i choose a specific-global-unshared-groupWritable directory to store all my CNID DBs ?

Thanks in advance for your time and help.
Pierre

 

[pierrep]

Looks like gcooper is very busy with 8.0.3 at the moment, but is there that few people using a multi user AFP without giving full access rights to everyone that can help me out ?

 

[peterh]

I'm not a multiuser afp user but i use afp for a few things .. Some comments and observations ;
-why do you "mkdir toto" ( make a directory in your toplevel zfs pool ) ? Why don't you
create a zfs filesystem "toto" and export that instead? That way your users should not be

able to fill up all of your pool but be constrained to the filesystem toto ( which you can control the size
of and in the future use user quota to control each users demands )

As i see from my own filesystems root ownes and operates '.AppleDB' :
here is "ls -l" from a pool where several filesystems are grafted, iphoto - well you guess
[root@fnas] /mnt/fnas# ll
total 100
drwxr-xr-x 9 root wheel 9 Dec 25 12:34 ./
drwxr-xr-x 4 root wheel 512 Nov 14 19:33 ../
drwxr-xr-x 10 root wheel 11 Nov 14 21:49 arkiv/
drwxr-xr-x 8 peter wheel 9 Dec 26 11:47 eyetv/
drwxr-xr-x 8 peter wheel 10 Dec 25 20:34 iphoto/
drwxr-xr-x 8 root wheel 10 Dec 25 11:54 public/
drwxr-xr-x 3 root wheel 3 Nov 12 22:21 replica/
drwxr-xr-x 8 peter wheel 9 Dec 26 10:59 tmmedia/
drwxr-xr-x 8 peter wheel 9 Dec 26 11:40 tmynk/

[root@fnas] /mnt/fnas# ll iphoto/
total 150
drwxr-xr-x 8 peter wheel 10 Dec 25 20:34 ./
drwxr-xr-x 9 root wheel 9 Dec 25 12:34 ../
drwxr-xr-x 2 root wheel 13 Dec 25 13:15 .AppleDB/
drwxr-xr-x 2 peter wheel 3 Dec 25 12:45 .AppleDesktop/
drwxr-xr-x 2 peter wheel 5 Dec 25 16:11 .AppleDouble/
-rw-r--r-- 1 peter wheel 6148 Dec 25 16:11 .DS_Store
drwxr-xr-x 3 peter wheel 3 Dec 25 12:45 Network Trash Folder/
drwxr-xr-x 3 peter wheel 3 Dec 25 12:45 Temporary Items/
-rw-r--r-- 1 peter wheel 23204 Sep 15 2010 chuck.jpg
drwx--S--- 7 peter wheel 19 Dec 25 20:34 iPhoto Library/


The 'S' ( big S ) in the iPhoto Library is from the manpage :
S If in the owner permissions, the file is not exe-
cutable and set-user-ID mode is set. If in the
group permissions, the file is not executable and
set-group-ID mode is set.

That is : it's not browsable and all files with be owned by group.

Happy Xmas

 

[gcooper]

i thought i should not pollute the 8.0.3 near-release announcement post so i'll continue here.
The command you requested returned nothing (no .AppleDesktop file or directory in my dataset)
This is probably because the root directory of the dataset is not writable to the user that's accessing it which is the default setting since 8.0-R and i did not change anything there.

Plus i like it like that, it allows me to control the first level directories so that users do not clutter said directory.

(I believe we discussed this before, but just to reiterate) The error message means "I couldn't create the files I needed to store the volume info" (which is related to, but not exactly the same as the CNID DB). This is hinting that there's a permissions issue creating the file at the root of the share, not the subdirector(y)/(ies).

So i tried to create a new dataset from scratch and sharing it, like i did in 8.0-R
Here's the log :

...

So... should i *really* put the first level directory writable to the "users" group (or world) for AFP to work properly ?
This was apparently not the case in 8.0-R (as i mentioned already a few times and this would allow them to create whatever they want at first level.

I do not really have a lot of time to retest this with 8.0-R to make sure that what i'm saying is actually true in that version, but that's how i remember it.

If you have any idea on how to achieve what i want, i'd be glad.
Should i choose a specific-global-unshared-groupWritable directory to store all my CNID DBs ?

Yes, you should make the file/directory group-writable so everyone can modify the CNID DB file, e.g.

Code:

chown -R u+g pierre:users toto
chmod -R 0775 toto

Then adjust the permissions according to how you want users to be able to access the share.

Thanks in advance for your time and help.

np!