This is caused by directories not being automounted when the container is run. I had thought that /usr/groups/thing was the automount point, but evidently the sub-directories are auto-mounted individually. The solution is to make sure each one is mounted before entering the container:
$ (cd /usr/groups/thing/foo; cd /usr/groups/thing/bar)
$ docker run -v /...
I experienced something similar.
That is, logins of users with automounted home directories hung right after reboot, until such time as I manually started rpcbind with "systemctl start rpcbind". This is with all the most recent Cent7 updates as of today.
I found that modifying the autofs unit file to depend on rpcbind and some other services fixed my ...
Since I just spent my entire morning debugging this same issue. Let me explain what happened above.
## Mount this test share:
/test /etc/auto.test --timeout=60
This means I want to mount something at /test and for the details read /etc/auto.test
I found the answer : you have to use the option nounix together with file_mode and dir_mode
Here is my fstab :
//adsrv01/Photos /mnt/Photos cifs credentials=/root/credentials.txt,file_mode=0770,dir_mode=0770,nounix,uid=505,gid=505 0 0
You can launch your spot instance with a persistent EBS root volume (or attach a separate EBS volume post-boot). The EBS volume will remain after your spot instance terminates.
I suppose the credentials file will be read by mount.cifs, like for other CIFS mounts. So I had a look at the mount.cifs.c source file in the current cifs-utils code, which should be for version 6.3. The code for reading the password does no unescaping, except that every comma is doubled in the password field of the parsed_mount_info struct, as is apparently ...
You can get the informations from this link: Ubuntu community, Autofs, 3.1.1. Direct and Indirect Maps
"Direct maps create a mount-point at the path specified in the relevant map file. The mount-point entry in auto.master is always /-"
Let's create our mount-points, and add lines to /etc/auto.master
Source is: http://wiki.centos.org/TipsAndTricks/WindowsShares at point "5. Yet Another Even-better method"
The trick is to use autofs:
Add this line to /etc/auto.master:
Create /etc/auto.smb.top as:
* -fstype=autofs,-Dhost=& file:/etc/auto.smb.sub
Create /etc/auto.smb.sub as (adjust as needed):
It's actually hard to argue one way or the other. The only item I can point out (happened to me) is that if you are using static mounts as in fstab and someone/thing makes an error the system may not boot and you'll have to go into rescue mode to get the system back online. That won't happen when using autofs.
I was expecting autofs to show the NFS server name/IP under the /net mount directory and then show the server's exports under that.
So when I did:
and saw nothing, I concluded it wasn't working.
In fact, what I needed to do was:
and then the exports magically tuned up because I was "accessing" them, which is what ...
This is the root cause of the problem:
systemd starts sssd first
sssd is configured as a forking process in sssd. sssd doesn't signal systemd when it's fully loaded. After startup systemd considers sssd as loaded and continues the startup process.
In some cases it can take a while before sssd is loaded and starts answering autofs/passwd/... nss queries. I ...
It looks like your NFS shares are being exported with root_squash enabled, so the root user actually gets the permissions of nobody when trying to operate on NFS mounts. Look for a root or root squash option in your NAS exports and tweak that.
What you might be able to do is have them combined into one, say foo+bar, so it will be one argument, then have the executable map script split on the + and use the results as the two path parts to use. But as far as I know autofs (and really any mounting) only takes one argument for the path to mount on, not two.
It's most likely that you're running into an NFS permissions issue. In a standard setup, NFS client machines are not trusted for root access on the NFS server; access by uid=0 is mapped to an unprivileged user (nfsnobody or similar). In order to create the home directory, pam_mkdir (which runs as root) would need to have permissions to the directory in which ...
I got it working.
For reference, here is a working autofs with WebDAV setup
$ sudo apt-get install autofs
$ sudo apt-get install davfs2
storage-folder -fstype=davfs,ro :https\://servername.mydomain.com\:3333/Shared.Folder
Note: change "ro" [read ...
I found the solution/mistake, leaving it here in case somebody else finds themselves in this situation. As it turns out, the mistake resided in the mount command. The correct command should be automountInformation: -fstype=cifs,rw,username=<some-user>,password=<some-password>,uid=&,gid=<some-groupname> ://fileserver/share/&.
OK, I've figured it out.
I tried to directly run:
sudo sshfs email@example.com:/root /tmp/10/ -o reconnect,allow_other,follow_symlinks,ssh_command='ssh HostKeyAlgorithms=ssh-dss'
and it gave me an error:
read: Connection reset by peer
So, it didn't work. I started looking for a way to fix it and found out, that in order to do it, I have to configure 2 ...
Feeling so dumb right now. It was because anotherfolder wasn't in the /etc/exports on the source machine. I added it an did a reload and the client was allowed to mount it.
From the autofs man page:
Map Key Substitution
An & character in the location is expanded to the value of the key field that matched the line (which probably only makes sense together with a wildcard key).
A map key of * denotes a wild-card entry. This entry is consulted if the specified key does not exist in the map. A typical wild-card ...
It should be due to this on your automount configuration:
You have to add ://192.168.1.2/scrolls the : is required for smb shares when using autofs
[root@rhel7-client /]# cat /etc/auto.shares
scrolls -cifs,credentials=/etc/creds.txt ://192.168.1.2/scrolls
In general, if you experience problems with idmapping you need:
check that client can talk to LDAP/NIS server
clean idmap cache by running 'nfsidmap -c'
start rpc.idmapd in in a debug mode
(rpc.idmapd -f -v) and watch the requests.
1.Make USB device base name permanent(eg: Iomega usb device)
To avoid any confusion whether base name for your USB block device is /dev/sdb1, /dev/sdd1 or /dev/sdXn we make it permanently /dev/Iomega anytime you plug it in. This can be done with help of udev device manager. You should have udev already installed on your system, otherwise install it with:
Spot instances (and really all of EC2) are optimized for use cases where you don't need to maintain state. When you configured your spot instance request, you provided an AMI id which each instance uses to boot. As you've found, changes do not get committed back to that AMI.
If you truly need a shared filesystem, configure a long-running (non-spot-instance) ...
I don't know if this is way too late to answer this, but for anybody else having this issue, I just spent a couple of hours banging my head against a wall with a CentOS6 VM trying to access cifs shares on the Windows 7 host.
In the end, what worked for me was changing the password line in the credentials file to use "pass" as the parameter name. e.g.
Do you possibly have any spaces in the file, perhaps between the = signs? a -13 error can be caused by spaces in the creds file, as per the following link. http://thinkinginsoftware.blogspot.com/2011/09/cifs-vfs-cifsmount-failed-return-code.html
My own thinking also wonders if this might be due to an encoding issue with the file itself. What does file -bi ...
I know this is pretty late to the party, but was the nfs-server service started on server B? I just ran into these exact symptoms, and that was the solution. Try running service nfs-server start on server B.