-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Drive redirection features
This page summarises the drive redirection features available in XRDP 0.9.12 and later.
- Hard links and soft links are not supported.
- Setuid, setgid and sticky permissions bits are not supported.
- POSIX file locking is not yet implemented, but this looks possible if there is demand for such a feature.
If Drives that I plug in later is selected in the Windows RDP client configuration, removable drives which are plugged-in (and removed) on the Windows client will appear (and disappear) on the Linux side.
All files in redirected drives will have the UID and GID of the logged-in user, regardless of who owns the files on the Windows client.
For security reasons, a umask of 077 is applied to file permissions on redirected drives. This prevents logged-in users from being able to access redirected drives of other users. If however, you wish your users to be able to access each other's Windows files, you can change the value of FileUmask in the [Chansrv] section of sesman.ini.
All directories and files on redirected drives will have the user readable bit set, regardless of whether or not the file is actually readable in practice.
For both directories and files, the user writeable bit on the Linux side maps to the negated Windows read-only file attribute. So, for example, clearing the user writable bit on the Linux side will make the file read-only in Windows.
Directories on redirected drives always have the user executable bit set, regardless of whether or not the directory is searchable by the user.
For normal files, the user executable bit on the Linux side maps to the Windows system file attribute. This allows the user to create executables, or executable scripts on redirected drives.
When using the default FileUmask of 077, group and other permissions will always be unset.
If you change FileUmask, the unmasked group and other permissions will track the user permissions. Setting group or other permissions on the Linux side has no effect - these bits will always track the user permissions.
The UNIX atime and mtime file attributes are mapped through to Windows access and modified times respectively.
The UNIX ctime attribute is maintained locally as some target Windows file systems do not support this attribute.
This section details situations where the redirected drives exhibit unusual behaviours by POSIX standards.
Because of the permissions model, file or directories may appear to be accessible from their permissions bits, but attempts to access the files or directories will fail:-
$ cd ~/thinclient_drives/C\:/Windows/System32
$ ls -ld config
drwx------ 1 <uid> <gid> 0 Dec 13 12:11 config
$ ls -l config
ls: cannot open directory 'config': Permission denied
POSIX allows users to remove read-only objects from a file system if the user has write permissions to the enclosing directory. Windows does not allow read-only objects to be deleted in the same way. It is necessary to remove the read-only bit before objects can be deleted:-
$ cd ~/thinclient_drives/C\:/Users/<user>/Documents/
$ mkdir temp
$ touch temp/temp.txt
$ chmod u-w temp/temp.txt
$ ls -l temp/temp.txt
-r-------- 1 <uid> <gid> 0 Dec 13 12:40 temp/temp.txt
$ rm -rf temp
rm: cannot remove 'temp/temp.txt': Permission denied
$ chmod -R u+w temp
$ rm -rf temp
An idiom occasionally used in POSIX is to open a file for reading, and then delete it while it is open. This idiom doesn't work well with Windows. Although it looks like it should be possible from the available APIs, the existing Windows RDP clients don't appear to support it:-
$ cd ~/thinclient_drives/C\:/Users/<user>/Documents/
$ touch temp.txt
$ exec 3<temp.txt
$ rm temp.txt
rm: cannot remove 'temp.txt': Permission denied
$ exec 3<&-
$ rm temp.txt
Some filenames which are allowable under POSIX simply can't be created on Windows:-
$ cd ~/thinclient_drives/C\:/Users/<user>/Documents/
$ touch nul
touch: cannot touch 'nul': Input/output error
$ touch :
touch: cannot touch ':': Input/output error
Windows is case-insensitive which can lead to some strange behaviours:-
$ cd ~/thinclient_drives/C\:/Users/<user>/Documents/
$ echo "Here is some data" >temp.txt
$ cat TEMP.TXT
Here is some data
$ cat TeMp.TxT
Here is some data
$ ls
applications 'My Pictures' TeMp.TxT 'My Videos' TEMP.TXT
desktop.ini 'My Music' temp.txt