A "device" is everything with an entry in /dev. In fact this entry in /dev is the device as far as the system is concerned. This is one of the most basic tenets in Unix.

Perhaps you want a less axiomatic answer, so here is the long version:

The kernel doesn't interact with hardware itself but leaves this task to drivers. Drivers are mostly loadable kernel modules (they become part of the kernel image when they are loaded) and their task is twofold: they have to drive the hardware and they have to offer interfaces to the other processes.

Lets have an example: consider a disk driver. Some process wants to write data, so the disk driver has to have some way of getting told by the process about the data to be written. On the other hand it has to translate this to some low-level commands the disk understands (SCSI commands for SCSI disks or ST-506 commands for ancient MFM disks or whatever).

We are interested in the interfacing to other processes here. This is in Unix traditionally done by an entry in /dev. It acts quite similar to any file: writing to there means telling the device driver to transfer data to this device, reading from there tells the device driver to get data from the device. This principle is the same for most devices: writing to /dev/tty<x> means to have this written to the screen of the respective terminal, reading from there means waiting for keyboard input; writing to (do NOT TRY THIS!) /dev/hd<x> means writing to this disk, reading from there means reading the disks data; and so on.

What does that mean for your question? When the LVM (Logical Volume Manager) creates an LV (a "Logical Volume", basically a [virtual] disk) it creates an entry /dev/hd<x> which represents this disk. Later you tell the filesystem driver (a higher driver level, which operates on top of the LVM) to "mount" this device somewhere, which basically means to make the content of the device accessible via filesystem means.

The "rename" facility in "ftp" is what its name suggests: a means to rename (but not move!) a file. To rename it means to change the contents of its inode. (This is the place where the filesystem stores some vital information about every file - including its name.) But if you "rename" the file from one filesystem to another you have to physically move the contents of the file from one disk to another disk. This means not altering the files inode, but moving the file, deleting the old inode and creating a new one on the new filesystem.

Usually Unix does a very good job in blurring this distinction, because "mv" will do both and in principle a user should not be bothered with how the filesystems are mounted. This is one of the few occasions where the distinction is made.

What you can do: get yourself the permission for the file to move it. There is no other way, otherwise Unix would not be the epitome of a secure OS it in fact is. If someone lacks permission for a specific task it should not and must not be possible to circumvent it - period. Works as designed.

I hope this helps.

bakunin