Samba installation stores mount.cifs in wrong location

[Jeff Davis]

The Samba installation instructions result in mount.cifs and umount.cifs installed into /usr/sbin. The mount program expects them to be installed in /sbin, per the mount man page. Unfortunately, mount does not complain about this, and merrily attempts to mount cifs files - always unsuccessfully. The error message is rather obscure, implying that there's an NT_AUTHENTICATION_ERROR. My solution is to move these two files into /sbin.

[Randy McMurchy]

I'll wait for others to comment, but I think it is more a bug in mount than with Samba. Samba requires networking, which typically is not activated in single-user mode (if I recall correctly). And if Samba is not required in single user mode, then its files do not belong in /sbin.

Comments are welcome. DJ should have good input on this, as well as Bruce.

[bdubbs@…]

I took a look at the coreutils source and they have a comment:

* A file system is `remote' if its Fs_name contains a `:'
   or if (it is of type (smbfs or cifs) and its Fs_name starts with `//').  */

but I don't see where it is searching for mount.cifs. We do build Samba with --prefix=/usr, so moving these files to /sbin may be the right thing to do.

[DJ Lucas]

Randy's assessment of the FHS guidelines is correct regarding the runlevel requirement of programs in /usr, however, there is nothing stopping you from mounting a cifs share with extended atrributes as /usr. So, per FHS guidelines, the mount.cifs program does belong in /sbin. The same goes for any other filesystem related programs that require a mount or fsck helper, such as dosfstools, reiserfs-progs, e2fsprogs, ntfsprogs, and probably some fo the programs from fuse, among others.

Bruce: Util-linux-ng-2.18/mount/mount.c: check_special_mountprog(), specifically FS_SEARCH_PATH which is defined in configure by fs_paths_defaults="/sbin:/sbin/fs.d:/sbin/fs". While we could include /usr/sbin in the mount search path, this would likely not be correct unless a filesystem requires other programs that are in /usr, in which case they too should be moved to the root filesystem.

[bdubbs@…]

Replying to dj@…:

Bruce: Util-linux-ng-2.18/mount/mount.c: check_special_mountprog(), specifically FS_SEARCH_PATH which is defined in configure by fs_paths_defaults="/sbin:/sbin/fs.d:/sbin/fs". While we could include /usr/sbin in the mount search path, this would likely not be correct unless a filesystem requires other programs that are in /usr, in which case they too should be moved to the root filesystem.

Silly me. I was thinking util-linux and searching in coreutils.

As far as your point about mounting /usr as cifs, I think that it is the same as any remote mount of /usr. I agree with your comment that any mount/umount/mkfs/fsck support program should be in /sbin.

[Jeff Davis]

Confirmed that the problem still exists in the update to Samba 3.5.6

[Randy McMurchy]

Yes, it still exists. It was not addressed in the update to 3.5.6. It is a completely separate issue. I would like to become more knowledgeable about this subject. Any follow up information would really help me out.

DJ's comment makes sense to me, so perhaps I'm on the right track. DJ, are you saying that after the filesystems are mounted (local ones in /etc/fstab), and then networking is started (that is the order that happens in my boot sequence), you would then mount a remote cifs share as /usr?

What confuses me is that in my fstab (though commented out right now; however, it used to not be commented out) I have NFS filesystems mounted, which would be called before networking is available. I am sort of confused with how that worked. Any cluebat for me would be helpful.

[bdubbs@…]

Just guessing here, but IIRC cifs is a local only networking protocol. It works at the link layer and the network layer does not need to be initialized.

[Randy McMurchy]

Replying to bdubbs@…:

Just guessing here, but IIRC cifs is a local only networking protocol. It works at the link layer and the network layer does not need to be initialized.

Sorry for being so dense and furthermore too lazy to do my own research, but how does my linux box communicate with my windows box if my linux network card has yet to be initialized?

[Jeff Davis]

OK, I probably wasn't completely clear about what the problem is - I was focused on the solutions :).

The problem is independent of whether the mount is mentioned in /etc/fstab or not. It can be seen when attempting to mount a cifs filesystem from the command line.

For example, suppose I'm logged in, and want to access a share on my Windows 7 machine. I would enter:

mount -t cifs geek/public_share /mnt/cifs -o user=jeff

This causes mount to look for its helper, mount.cifs, in the /sbin directory. Since it's not there, mount makes a valiant attempt to connect anyway. It even asks for my password, but I don't get the mount. I get an error indicating that there's an NT_AUTHENTICATION_ERROR.

When mount.cifs (and its companion, umount.cifs) are moved from /usr/sbin to /sbin, everything connects and works perfectly.

Hope this helps.

[Randy McMurchy]

After a little research, most distros are symlinking mount.cifs in /sbin. I don't see any reason to symlink. Installing the mount.cifs and umount.cifs in /sbin seems the most logical solution. Though I consider it a bug in the mount program (no program should hard-code a path), why fight it?

I'll make a change to the Samba instructions to move the two files into /sbin. Thanks for the report and the very nice explanation.

[DJ Lucas]

Replying to randy@…:

After a little research, most distros are symlinking mount.cifs in /sbin. I don't see any reason to symlink. Installing the mount.cifs and umount.cifs in /sbin seems the most logical solution. Though I consider it a bug in the mount program (no program should hard-code a path), why fight it?

I'll make a change to the Samba instructions to move the two files into /sbin. Thanks for the report and the very nice explanation.

Regarding your earlier comment (7?), I'm guessing the netfs boot script, or more likely the _netdev option in /etc/fstab. /usr as a network mount used to be very common, or so I'm told. I've honestly only seen it once in a school lab, but maybe that is due to my late entry in the field. This is why the FHS says that items that must be started before networking is up, must be on local file systems. Given that situation, or possible situation, the mount helpers must be available on the local file system, or /usr would not be available to mount /usr. I would say that the distro maintainers got it wrong if they are symlinking the files. Looks like Ubuntu is using fusefs (which avoids the problem completely), but I don't have any others to compare with.

[DJ Lucas]

Forgot to add, only my opinion, that util-linux is probably is doing "the right thing" to enforce specific paths.

[Randy McMurchy]

Though I know what needs to be done, and whether or not util-linux does "the right thing" or not doesn't matter (I say it is wrong, there is no reason mount cannot use the standard user's path to find what it needs), the fundamental question I've asked has not been answered. Or at least I am not understanding Bruce's answer.

How does a Samba tool mount a remote share if networking is not available?

[Randy McMurchy]

Noted while browsing the mount.cifs.c source code, it is highly recommended that it is NOT run setuid. Our BLFS instructions indicate it is okay to do that. In fact, our instructions are wrong because the code will look to see if it is run suid by an unprivileged user and exit with a warning message if you try to do it. I suppose the note about setting the programs suid should be removed.

[Randy McMurchy]

I'm hoping someone will help me decipher this code from the mount.cifs.c program source

 /* allow for either delimiter between host and sharename */
                        if ((share = strpbrk(unc_name, "/\\"))) {
                                *share = 0;  /* temporarily terminate the string */
                                share += 1;
                                if(got_ip == 0) {
                                        rc = getaddrinfo(unc_name, NULL, NULL, &addrlist);
                                        if (rc != 0) {
                                                fprintf(stderr, "mount error: could not resolve address for %s: %s\n",
                                                        unc_name, gai_strerror(rc));
                                                addrlist = NULL;
                                        }
                                }
                                *(share - 1) = '/'; /* put delimiter back */

and

 flags &= ~(MS_USERS|MS_USER);

        addrhead = addr = parse_server(&share_name);
        if((addrhead == NULL) && (got_ip == 0)) {
                fprintf(stderr, "No ip address specified and hostname not found\n");
                rc = EX_USAGE;
                goto mount_exit;
        }

If you `man getaddrinfo' and read about this Glibc function, it implies that it must do conventional host resolution or a direct IP address. How would this work if networking was not initialized?

[DJ Lucas]

Replying to randy@…:

Though I know what needs to be done, and whether or not util-linux does "the right thing" or not doesn't matter (I say it is wrong, there is no reason mount cannot use the standard user's path to find what it needs), the fundamental question I've asked has not been answered. Or at least I am not understanding Bruce's answer.

Oh now I understand. Above, I was referring to their decision to enforce the FHS by default. There is still a way to override that setting.

How does a Samba tool mount a remote share if networking is not available?

AFAICT, it is not possible. Unless maybe there is a concept of persistent and disconnected shares when using winbindd, but I don't think it is quite that advanced, or at least I've never heard of it. I can't speculate on Bruce's comments however, kinda threw me too. Referring to smbd and a local mount on loopback maybe? If you have the _netdev or noauto options in /etc/fstab, mountfs will skip the mount, and netfs will catch it after network is up in the case of _netdev.

[bdubbs@…]

I didn't mean to throw out a red herring. Setting up a system to mount a cifs partition as /usr seems to be a pretty dumb thing to do. On the other hand, setting up a central nfs partition for multiple systems to use for /usr seems like a reasonable thing to do to make updates on that central system easier and more secure.

As long as /usr is available, it doesn't make much difference whether cifs support is in /sbin or /usr/sbin.

[bdubbs@…]

In the current build instructions mount.cifs is in /sbin. I'm not sure when that happened, but in any case, it's fixed.

[bdubbs@…]

Milestone 6.7 deleted