How can I move a file to another user’s directory?
I’m using CentOS 6 and I’m trying to move a file from USER A to USER B but I keep getting permission denied. What do I need to edit to allow to me to put files from one user’s directory into another’s?
3 Answers 3
You need the rights to read the file from user A, and to write the file to user B’s location.
There are several ways to archive this:
1)
As user A (assumed she can read her own files) get WRITE permission to user B’s location. This means being in a group which is allowed to w to the destination directory and which is allowed to access (x) the directory path to the destination.
cd /home/user/A/ ls -l testfile -rw------- 1 userA users 18 Dec 31 16:31 testfile Notice the r. User A is allowed to read her own file
cp testfile /home/userB/testdir User A will need to traverse to the folders /home, /home/userB and /home/userB/testdir. All of these need to be ‘x’ for her. She wants to write to the folder ‘testdir’ and thus she also needs ‘w’ on that folder.
That ‘w’ can be in the user, group or other part. But if you set it in ‘other’ then every user can write to it. Thus you usually make shared files or shared folders part of a group. (e.g. in /etc/group create a group ‘sales’ and add both users to that).
2)
As user B: (which is assumed to be able to write in his own folder).
Get read permission on the file in userA’s folder and the right to traverse there. (same as in 1).
You now can copy the file to your own location. You can not delete it from user A’s folder unless you also have the rights to do that. So you can copy but not move.
3)
As a user with uid 0 (usually root, toor, admin):
mv /home/userA/testfile /home/userB/
Notice that the file is still owned by userA, and that user B might not have the rights to work on the file. You can correct this with chown .
4)
Without the heavy guns, as often done by two users:
As UserA: cp testfile /tmp/ As userB: cp /tmp/testfile ~ As userA: rm /tmp/testfile This is not the most secure way (other can see the file while it is in /tmp), but I think that this is the most common solution.
If you want to do this often then I strongly suggest creating a group and giving all users in that group rights to a shared location.
Not asked, but a solution like this is often practical (shown with music, but it might as well be sales reports).
vim /etc/group and add a line like this: shared_music:*:3141:userA,UserB,UserC . This will create a group called shared_music, give it a number, and select which users will belong to that group.
Then make folder owned by that group.
cd /usr/local/ md our_ultimate_shared_music_collection chgrp shared_music our_ultimate_shared_music_collection chmod g+rwx our_ultimate_shared_music_collection chmod g+S our_ultimate_shared_music_collection Make a folder in a sane location. Set the group and then allow all people in that group to read, write and cd into that folder. The last command (make group setuid) means that newly created subfiles inherit the same group as the directory, and newly created subdirectories inherit the set-group-ID bit of the parent directory. This prevent userA from writing files to that directory which USerB (or anyone but A) could not deleted or rename.
How to move a file in Linux
Whether you’re new to moving files in Linux or experienced, you’ll learn something in this in-depth writeup.
Moving files in Linux can seem relatively straightforward, but there are more options available than most realize. This article teaches beginners how to move files in the GUI and on the command line, but also explains what’s actually happening under the hood, and addresses command line options that many experience users have rarely explored.
Moving what?
Before delving into moving files, it’s worth taking a closer look at what actually happens when moving file system objects. When a file is created, it is assigned to an inode, which is a fixed point in a file system that’s used for data storage. You can find what inode maps to a file with the ls command:
$ ls --inode example.txt 7344977 example.txt When you move a file, you don’t actually move the data from one inode to another, you only assign the file object a new name or file path. In fact, a file retains its permissions when it’s moved, because moving a file doesn’t change or re-create it.
File and directory inodes never imply inheritance and are dictated by the filesystem itself. Inode assignment is sequential based on when the file was created and is entirely independent of how you organize your computer. A file «inside» a directory may have a lower inode number than its parent directory, or a higher one. For example:
$ mkdir foo $ mv example.txt foo $ ls --inode 7476865 foo $ ls --inode foo 7344977 example.txt When moving a file from one hard drive to another, however, the inode is very likely to change. This happens because the new data has to be written onto a new filesystem. For this reason, in Linux the act of moving and renaming files is literally the same action. Whether you move a file to another directory or to the same directory with a new name, both actions are performed by the same underlying program.
This article focuses on moving files from one directory to another.
Moving with a mouse
The GUI is a friendly and, to most people, familiar layer of abstraction on top of a complex collection of binary data. It’s also the first and most intuitive way to move files on Linux. If you’re used to the desktop experience, in a generic sense, then you probably already know how to move files around your hard drive. In the GNOME desktop, for instance, the default action when dragging and dropping a file from one window to another is to move the file rather than to copy it, so it’s probably one of the most intuitive actions on the desktop:
The Dolphin file manager in the KDE Plasma desktop defaults to prompting the user for an action. Holding the Shift key while dragging a file forces a move action:
Permissions required to move file to different directory in Unix/Linux [closed]
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
- The user/group doing the move must have write permission for directory B (or B must have permission flag set to allow all users/groups to write it)
- The user/group doing the move must have write permission for directory C (or C must have permission flag set to allow all users/groups to write it)
- The user/group doing the move must have write permission for file A (or A must have permission flag set to allow all users/groups to write it)
But here we also have a tag file-permissions , so read it as «what conditions do I have to check before I let my script perform a mv of the specified kind» 😉
Sorry I did not know there is another site for UNIX questions. I will bear this in mind for the future.
1 Answer 1
Actually, moving a file is either a rename of a file on a single file system or creating a copy and deleting the original (typically only done if the move is a migration from one file system to another).
In either case you need execute and of course write permissions to the target directory and the source directory. However, for a mere rename (and moving from one directory to another can be just that) on a single file system you do not need any permissions on the file itself. It can be cleared of all permissions and still you can move (rename) it (as long as you have write and execute permissions for the directories).
For a real copy (as it is needed when you move the file to a different file system), you need read permissions on the file itself. No write permissions on the original are necessary, as deletion of a file is not writing to it (but to the directory it is in).
How to move a file without preserving permissions
The problem is I want to be able to see errors when moving a file, but not see errors with permissions problem. In other words — I care if the file is not fully transmitted, but don’t want to see errors like this:
So I want something like: mv $backupfile $destination —ignore-permissions . The backup file can be anything from 1 MiB to 5 GiB and is transfered through NFS.
It happens also on connected NTFS device, but this is not the only case. It happens in all cases were you do not have rights to change permissions or it is not possible (like on NTFS).
This is useful when trying to move files that somehow don’t get moved because of permissions errors (e.g. because they are mounted over cifs ).
For me it also happens when moving a file into an sshfs mount, even if it’s mounted with -o idmap=user , because the gid does not get mapped (even with -o gidfile ).
2 Answers 2
mv is the wrong tool for this job; you want cp and then rm . Since you’re moving the file to another filesystem this is exactly what mv is doing behind the scenes anyway, except that mv is also trying to preserve file permission bits and owner/group information. This is because mv would preserve that information if it were moving a file within the same filesystem and mv tries to behave the same way in both situations. Since you don’t care about the preservation of file permission bits and owner/group information, don’t use that tool. Use cp —no-preserve=mode and rm instead.
Thanks, it works. Ended up doing: cp —no-preserve=mode,ownership $backupfile $destination , check exit code and then do rm $backupfile if everything is fine.
When you move a file within the same filesystem, mv detaches the file from its old location and attaches it to its new location; metadata such as permissions remains the same. When you move a file to a different filesystem, mv copies the file, attempts to replicate as much metadata as possible, and removes the original.
Since you’re moving to a different filesystem and you don’t want to replicate much metadata, you might as well copy the file then remove the original.
cp "$backupfile" "$destination" && rm "$backupfile" This preserves the file’s permissions to some extent (e.g. world-readability, executability). The file’s modification time isn’t preserved. With GNU cp , you can use the —preserve=… option to contol what metadata is replicated more finely, e.g. —preserve=mode,timestamps .
You can also use rsync and tell it what you want to preserve. The option -a means “preserve most metadata”, which includes the owner if running as root only.
rsync -a --no-owner --no-group --remove-source-files "$backupfile" "$destination"