More mount problems

Ook · 02-22-2014, 11:17 PM

Once upon a time I had this working. To mount a share on a machine running a 3.8+ kernel, I simply added -o sec=ntlm to the mount command. Worked great.

I can mount the share on the 3.2.x kernel box. I can NOT mount the shares on the 3.10.x box but instead get permission denied.

More info: I have three boxes. Box A has 3.2.45 kernel. Box B and C have 3.10.17. All three boxes have identical samba config except for the [name] line:

[ook] <-- or ooks1 or ooks2
path = /
read only = no
guest ok = yes
force user = root
forceuser = root

(yes yes I know I'm forcing user to be root. This is a testing environment).

I use this to mount the share on the 3.10.x kernel box:

mount //10.0.0.10/ooks1 /mnt/ooks1 -o sec=ntlm
Password:
mount error(13): Permission denied

If I try to mount a share on the 3.2.x kernel:

mount //10.0.0.2/ook /mnt/ook -o sec=ntlm.

It works fine.

What am I missing? What is the secret to mounting a share on a box running a 3.10.x kernel?

allend · 02-23-2014, 02:00 AM

Quote:

I have three boxes. Box A has 3.2.45 kernel. Box B and C have 3.10.17

You have three Linux boxes. I suggest you use NFS in place of Samba.
http://docs.slackware.com/howtos:net...home_nfs_howto
http://docs.slackware.com/howtos:net...nd_dirty_setup

Ook · 02-23-2014, 03:13 PM

Quote:

Originally Posted by allend

You have three Linux boxes. I suggest you use NFS in place of Samba.
http://docs.slackware.com/howtos:net...home_nfs_howto
http://docs.slackware.com/howtos:net...nd_dirty_setup

OMFG you have got to be kidding me!!! I have anguished over getting Samba to work for freakin' HOURS!!!!

Fifteen minutes and I have NFS working, and I can mount my shares.....<shakes head in disbelief>

What is the catch? How can getting Samba to work be such a hell on earth, and getting NFS working takes just 15 minutes?

Ook · 02-23-2014, 07:08 PM

Quote:

Originally Posted by allend

You have three Linux boxes. I suggest you use NFS in place of Samba.
http://docs.slackware.com/howtos:net...home_nfs_howto
http://docs.slackware.com/howtos:net...nd_dirty_setup

I actually have more than three, but I was just working with these three for now.

So anyhow I have NFS up and running and it seems to work good, but I have run across a problem that I don't know how to overcome.

On box B, the server, I have a partition, /dev/sda5 that is mounted as /opt. On box B I'm sharing the / directory (yeah yeah I know it's root, this is a test environment).

From box A, the client, I mount the box B share, which works fine. However, if I navigate into /opt, there are no files there. I have discovered that any and all partitions mounted on the server cannot be seen by the client. Everything else I have access to as expected.

Example: on the server box I have /opt and /temp and /home on different partitions. From the client, all three of these directories appear empty. So how do I go about getting access to these files? I've googled around but can't find anything discussing this topic.

allend · 02-23-2014, 08:31 PM

From 'man exports'

Code:

       nohide This option is based on the option of the same name provided in IRIX NFS.  Normally, if a server exports
              two  filesystems  one of which is mounted on the other, then the client will have to mount both filesys-
              tems explicitly to get access to them.  If it just mounts the parent, it will see an empty directory  at
              the place where the other filesystem is mounted.  That filesystem is "hidden".

              Setting  the  nohide  option on a filesystem causes it not to be hidden, and an appropriately authorised
              client will be able to move from the parent to that filesystem without noticing the change.

              However, some NFS clients do not cope well with this situation as, for instance, it is then possible for
              two files in the one apparent filesystem to have the same inode number.

              The  nohide  option  is currently only effective on single host exports.  It does not work reliably with
              netgroup, subnet, or wildcard exports.

              This option can be very useful in some situations, but it should be used with due care, and  only  after
              confirming that the client system copes with the situation effectively.

              The option can be explicitly disabled with hide.

Ook · 02-23-2014, 09:14 PM

Quote:

Originally Posted by allend

From 'man exports'

Code:

       nohide This option is based on the option of the same name provided in IRIX NFS.  Normally, if a server exports
              two  filesystems  one of which is mounted on the other, then the client will have to mount both filesys-
              tems explicitly to get access to them.  If it just mounts the parent, it will see an empty directory  at
              the place where the other filesystem is mounted.  That filesystem is "hidden".

              Setting  the  nohide  option on a filesystem causes it not to be hidden, and an appropriately authorised
              client will be able to move from the parent to that filesystem without noticing the change.

              However, some NFS clients do not cope well with this situation as, for instance, it is then possible for
              two files in the one apparent filesystem to have the same inode number.

              The  nohide  option  is currently only effective on single host exports.  It does not work reliably with
              netgroup, subnet, or wildcard exports.

              This option can be very useful in some situations, but it should be used with due care, and  only  after
              confirming that the client system copes with the situation effectively.

              The option can be explicitly disabled with hide.

I tried that. It didn't work. Not sure why. I'll have to play with it a bit more as I really need to get to those mounted partitions from the client. Seems to be a rather severe limitation, only allowing access by default to the the drive where / is mounted, and no others. Maybe I'm missing something.

Ook · 02-24-2014, 07:57 AM

Code:

crossmnt
    This option is similar to nohide but it makes it possible for clients to move from the filesystem marked with crossmnt to exported filesystems mounted on it. Thus when a child filesystem "B" is mounted on a parent "A", setting crossmnt on "A" has the same effect as setting "nohide" on B.

Would anyone like to comment if the solution to the problem of mounting a share and being able to see non-root mounted partitions on the server can be simply fixed by using crossmnt instead of nohide? Don't have the boxes available right now but would be interested in others experiences with this.

On the server, the home directory is on a second hard drive, and an entry in fstab auto-mounts it. With NFS, by default, if I connect to the server and navigate to the home directory, it appears empty. The description to nohide indicates it can allow me to see the mount, but has reliability problems. The description to crossmnt is rather sparse and simply indicates it overcomes this. Does it? If so, then why oh why does nohide even exist?.

Ook · 02-24-2014, 06:23 PM

So crossmnt did not work - I could not even get the share to mount, for reasons unknown to me.

At this point my initial elation about NFS being easy to install has crashed and burned. I removed NFS, I removed Samba 4.1.x, I installed samba 3.6.8 from the slackware 14.0 packages, and Samba now works.

If anyone has any suggestions as to 1) Why samba 4.1.x won't work and samba 3.6.8 does, or 2) why with crossmnt in exports config, NFS share won't even mount, I'm all ears (or eyes since this is the Internet after all).

I'm a go with what works kind of person, and I have wasted WAY too much time with samba 4.1.x and NFS. Samba 3.6.8 works, gets the job done, and until I find compelling reasons to change I'm going to stick with it. Because it works.

perbh · 02-25-2014, 02:23 PM

try sshfs (http://www.linuxquestions.org/questi...-a-4175492759/)

Ook · 02-25-2014, 08:15 PM

Quote:

Originally Posted by perbh

try sshfs (http://www.linuxquestions.org/questi...-a-4175492759/)

Installs on client: yes. No config. nice.
No install on server. nice.

Mounts. yes.
Access to shares mounted on shared share. yes.
Read/write access. yes.

Running a backup right now using sshfs instead of samba. Curious as to how well it well perform.

Interesting. So far so good. Having been burned so badly with the new Samba as well as nfs I'm being a bit cautious....

Ook · 02-25-2014, 09:42 PM

Well, the bandwidth is not exactly stellar, but considering it is going through SSH I think it isn't bad. I seem to be able to sustain about 120 mbps. Not entirely sure what kind of performance one should expect via SSH.

So - this works. So far.

Ook · 02-26-2014, 08:20 AM

Woah - just realized something. I have several servers running Slackware. I keep them as clean as possible, they don't have samba or nfs enabled, they are LAMP servers and I keep everything else off of them. With SSHFS I can now mount shares on them without having to touch them at all! Prior to this I was using the midnight commanders vfs via ssh (which is essentially the same thing sshfs does). SSHFS just got another brownie point...