Samba 4.22++ - RENAME_NOREPLACE w/o fallback?

[Stefan Metzmacher]

Hello Heiner,

> we noticed after upgrading from Samba 4.20 to 4.22.3 (and later), that
> directory creation on MacOS causes a weird folder creation "loop" when
> creating a new folder in MacOS Finder. Finder basically forever keeps
> creating new directories.
> 
> This is only when the underlying filesystem is BeeGFS, a parallel
> filesystem which does not support RENAME_NOREPLACE.
> 
> My question: Is there a mechanism to tell Samba to revert to previous
> behaviour of not using RENAME_NOREPLACE if the underlying filesystem does
> not support it?
> 
> I´ll copy their analysis here, running strace on the smbd process:
> 
> The problem seems to be at the end of this folder creation sequence:
> 
> 268306 10:18:32.645081 mkdirat(27,
> ".::TMPNAME:D:268306%13947819943702811000:untitled folder 3", 0775) = 0
> <0.000574>
> 268306 10:18:32.645728 openat(27,
> ".::TMPNAME:D:268306%13947819943702811000:untitled folder 3",
> O_RDONLY|O_NOFOLLOW|O_PATH|O_DIRECTORY) = 31 <0.000026>
> 268306 10:18:32.645805 fstat(31, {st_mode=S_IFDIR|S_ISGID|0775, st_size=0,
> ...}) = 0 <0.000034>
> 268306 10:18:32.645899 fstat(31, {st_mode=S_IFDIR|S_ISGID|0775, st_size=0,
> ...}) = 0 <0.000022>
> 268306 10:18:32.645974 getxattr("/proc/self/fd/31",
> "system.posix_acl_access", 0x7ffe67cad620, 132) = -1 EOPNOTSUPP (Operation
> not supported) <0.000038>
> 268306 10:18:32.646082 setxattr("/proc/self/fd/31", "user.DOSATTRIB",
> "\0\0\5\0\5\0\0\0\21\0\0\0\20\0\0\0\0\274(w\2769\334\1", 24, 0) = 0
> <0.000199>
> 268306 10:18:32.646423 renameat2(27,
> ".::TMPNAME:D:268306%13947819943702811000:untitled folder 3", 27, "untitled
> folder 3", RENAME_NOREPLACE) = -1 EINVAL (Invalid argument) <0.000167>
> 268306 10:18:32.646656 mkdirat(27, "untitled folder 3", 000) = 0 <0.000637>
> 268306 10:18:32.647406 renameat(27,
> ".::TMPNAME:D:268306%13947819943702811000:untitled folder 3", 27, "untitled
> folder 3") = -1 EEXIST (File exists) <0.000211>
> 
> Samba prepares the new directory in a temporary location that is probably
> hidden from the user to make the actual directory creation look atomic by
> renaming the temporary directory to the actual one in the end.
> There is an error with that renameat() which fails with EINVAL because
> RENAME_NOREPLACE is not supported in BeeGFS. This error is not communicated
> to the SMB client though.


You can use "vfs mkdir use tmp name = no".

I hope that helps!

metze