For auditing purposes I need to track all remotely mounted NFSv4 filesystems requests on an NFS server (CentOS7) to get both the identity of the mounting system AND the filesystem that they mounted. Using the 'netstat -an' command gets me the identity of the remote system but now I need to know what they mounted. It also gives no clue as to whether that system unmounted a file and then mounted a different one.
I have seen various references to both 'rmtab' and 'showmount' but they do not show me the currently mounted files and, from what I can see, they are only good for NFSv3 and older mounts. I have also seen reference to the file /proc/fs/nfsd/clients but cannot see such a file on any of my servers. Surely the information as to who has what mounted has to be available somewhere in the server even if it is a convoluted path to get there (auditing nfsservctl syscalls worked in olden days.)
Related to that, 'ps' shows me the '[nfsv4.1-svc]' process but I haven't been able to track down who/what/why that is and if it is useful.
Related
After successfully mounting the directory (ZFS remote storage) from one of the server, I'm getting an "Operation not permitted" error when I try changing the ownership of the directory. I'm using the following command:
To mount the remote directory:
mount -t nfs 10.1.32.33:/dir/temp/tools /home/materials
After mounting the directory, the contents are belongs to nobody:nobody
I want to change ownership so I can run the installer inside the directory.
I'm using the command below to change ownership but it's not working:
chown -R otm:otm materials/
I can always upload the file to the server without using the ZFS storage, however I want to start making a central installer repository so I don't need to upload the files/installers for future server install. I appreciate your help guys.
NFS servers by default do not allow root access to files - root is normally mapped to "nobody".
See "root squash":
Root squash[2][3] is a reduction of the access rights for the remote
superuser (root) when using identity authentication (local user is the
same as remote user). It is primarily a feature of NFS but may be
available on other systems as well.
This problem arises when a remote file system is shared by multiple
users. These users belong to one or multiple groups. In Unix, every
file and folder normally has separate permissions (read, write,
execute) for the owner (normally the creator of the file), for the
group to which the owner belongs, and for the "world" (all other
users). This allows restriction of read and write access only to the
authorized users while in general the NFS server must also be
protected by firewall.
A superuser has more rights than an ordinary user, being able to
change the file ownership, set arbitrary permissions, and access all
protected content. Even users that do need to have root access to
individual workstations may not be authorized for the similar actions
on a shared file system. Root squash reduces rights of the remote
root, making one no longer superuser. On UNIX like systems, root
squash option can be turned on and off in /etc/exports file on a
server side.
After implementing the root squash, the authorized superuser performs
restricted actions after logging into an NFS server directly and not
just by mounting the exported NFS folder.
In general, you DO NOT want to disable root squash unless you REALLY know what you're doing as there are serious security issues you can create if you do that. And since you didn't even know it exists...
(And that mention of /etc/exports is an extremely limited statement that is wrong on many systems - like Solaris.)
I accidentally deleted a user account, including the home directory (with userdel -r), and now I need to recover the contents of the home directory.
Is there a way to do this without umounting the filesystem or remounting the filesystem read-only?
Thanks
I wouldn't bet on that, but I believe there's no way to undelete files on a mounted read-write partition.
The main reason being that the longer you keep a filesystem up on a machine, the more likely the deallocated data will be overwritten by new stuff from apps and other users.
So instead of loosing time (and data!) trying to figure out a way, just immediately do a mount -o 'remount,ro' /home, and if you have a lot of users that will get angry at you because of that, then you dd if=/dev/sdXX of=home_partition_backup.img and once it's done, you mount -o 'remount,rw' /home.
Then you can do whatever undelete procedure you want on the image you've copied from the partition.
After using crashplan for a while, I noticed that several files aren't being backed up. The files are synced via unison (through cygwin) with another PC and while the *nix permissions are copied correctly, the mirrored file does not have SYSTEM as a user (in windows). Therefore, crashplan can't back it up. Both client and server are running cygwin.
What's the best solution? Can I copy this permission as well with unison? Can I do it with a script (in cygwin or cmd)?
Thanks
Sander
EDIT: To fix it short term I ran an icacls command, but I'm still looking for a way to copy the ACLs via unison whilst syncing.
Relevant section from the Unison Manual:
Permissions
Synchronizing the permission bits of files is slightly tricky when two different filesytems are involved (e.g., when synchronizing a Windows client and a Unix server). In detail, here's how it works:
When the permission bits of an existing file or directory are changed, the values of those bits that make sense on both operating systems will be propagated to the other replica. The other bits will not be changed.
When a newly created file is propagated to a remote replica, the permission bits that make sense in both operating systems are also propagated. The values of the other bits are set to default values (they are taken from the current umask, if the receiving host is a Unix system).
For security reasons, the Unix setuid and setgid bits are not propagated.
The Unix owner and group ids are not propagated. (What would this mean, in general?) All files are created with the owner and group of the server process.
If I open a file in my C/C++/Java code using a pathname that goes to an nfs directory, how the does the read and write syntax work with NFS being stateless and all? I have tried but cant find an example code accessing NFS mounted files. My current understanding is that it is the job of the NFS client to keep state (like read and write pointer) and the application uses the same syntax.
A related question is regarding VFS and UFS. Are all files in a current unix machine accessed through their vnodes first and then (depending on local vs remote) inode or rnode structures?
NFS (short of file locking) is no different than local storage to user-level applications. It might be slower, or it might drop out unexpectedly, but that can happen to local storage too. That's probably why you can't find specific NFS-centric example code.
I have several web applications in production that utilize NFS mounts to share resources (usually static asset files) among web heads. In the event that an NFS mount becomes unavailable, Apache will hang requesting files that cannot be accessed, the kernel will log:
Nov 2 14:21:20 server2 kernel: nfs: server server1 not responding, still trying
I reproduced the behavior in RHEL5 running NFS v3 and Apache 2.2.3:
Create an NFS Mount on Server1 (contents of my /etc/exports)
/srv/test_share server2(rw)
Mount the NFS share on Server2 (contents of my /etc/fstab)
server1:/srv/test_share /mnt/test_share nfs defaults 0 0
Setup a virtual host in Apache with a simple HTML file referencing image files stored on the NFS sharen
Load the site, the html and image files all return 200
Unmount the NFS Share, loading the page returns 404s for the images referenced
Remount the NFS Share
Simulate an NFS crash by turning NFS off on Server1 - reloading the site hangs retrieving the referenced files.
Internet searches so far have not turned up a good solution. Basically the desired behavior would be for the web server to return 404s and not hang until the NFS mount recovers.
Cheers,
Ben
couple of options:
get your nfs mount options right, you need to do a soft mount so nfs access can be interupted. try soft,intr,timeo=10 instead of default
sync your document roots with something else like rsync, or script yourself a semi-atomatic checkout/export from your SCM, if you use one. SCM use is recommended anyway, gives you the possibility to revert to the last working version, for instance
use a real distributed filesystem (preferably fault tolerant like coda) or even a distributed block device system like drdb
option 2 and 3 give you disconnected operation and are therefore much more robust than nfs. drdb is sexy, but my advice would be option 2 with somwething like git or svn, simple and robust
I would not directly serve from the NFS mount, but instead from your local filesystem.
It wouldn't be too hard to setup a cron job that synced the NFS mount to the local file system every few minutes. Apache would serve its content from there, not depending on the NFS mount. If the mount goes down, Apache would still be able to serve the assets, although they might be out of date until the NFS mount comes back up.