Bug 8381 - using shares on amd (am-utils) automounted pathes is broken.
Summary: using shares on amd (am-utils) automounted pathes is broken.
Status: RESOLVED FIXED
Alias: None
Product: Samba 3.6
Classification: Unclassified
Component: Config Files (show other bugs)
Version: 3.6.0
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Jeremy Allison
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-18 07:45 UTC by Marius Tolzmann (dead mail address)
Modified: 2024-07-12 10:49 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Marius Tolzmann (dead mail address) 2011-08-18 07:45:13 UTC
the amd automounter from the am-utils package mounts/symlinks directories on the fly.

say you want to access /some/data which may be local or remote the automounter will symlink this location (/some/data) on access to another directory which already exists locally or will be mounted from some remote machine.

/some/data is always a symlink to /another/directory

if /another/directory is mounted from a remote machine amd will unmount it after some timeout if it is no longer needed. when /some/data is accessed again /another/directory will be mounted again.

since samba introduced some kind of canonicalization in commit 02a5078f shares in automounted directories are broken: samba always tries to access /another/directory directly and the automounter is not triggered anymore.

because we disabled the unix-extensions-feature in our samba, we were able to locally reverted commit 02a5078f and am-utils+samba is working fine again.

to permanently fix this issue, samba needs to respect the fact that directories, once accessed, are not all the time accessible by their canonicalized representation and the configured directory for a share may always be checked first and if needed accessed again to make sure it really is available (again). (while the directory is used amd will not unmount it.)

no question, amd's behaviour is special and this issue is often called "the infamous readlink() issue".. but it is just the way it is 8)

if needed, we can provide more information and/or test possible fixes..

thanks, marius tolzmann..

p.s.: unsure about the correct component because i don't know where smbd issues are supposed to be located in.. i used "config files", because our configured pathes are not respected all the time. please move this issue to the right component. thx.
Comment 1 Jeremy Allison 2011-08-18 22:10:47 UTC
This is going to be hard to fix. The commit 02a5078f causes smbd to call realpath() on the connect path - this is to remove any "." and ".." elements in a provided path, and also to ensure there are no symlinks in the stored path.

This is important as we depend on a symlink-free path to remove problems with symlink races pointing outside of the share, and we also are using realpath() (as well as cd'ing into a directory to pin it) as part of the strategy to prevent problems with symlink races when accessing as root (no, this isn't as flakey as it sounds, there is a way of doing this that makes it completely robust :-).

This looks like a fundamental incompatibility between the way amd wants to do things and the way smbd wants to do things.

Jeremy.
Comment 2 Karolin Seeger 2011-08-20 18:53:01 UTC
Re-assigning to Jeremy.
Comment 3 Stefan Metzmacher 2024-07-12 10:49:26 UTC
This might be fixed with the following commits for 4.21:

ac7a16f9cc4bd97ef546d1b7b02605991000d0f9
03e9575e38d737e0972d4736a80949dcdb515c44
2aca5cfbfa45d2fcf00688388688812445123f3f

Otherwise 3.6 is no longer supported...