DSM-G600, DNS-3xx and NSA-220 Hack Forum

The ownership root vs nobody is not important, but the permissions are. Particularly in ffp/start as everything will try and start on a reboot. I have one of my setups owned by nobody (for a specifc reason) and do not have any issues with the packages I am running.

Personally, I'd copy the files you want to save (modified scripts, config files etc) then delete everything and reinstall ffp.

It should not be necessary to change the ownership or permissions to take a copy.

Last edited by FunFiler (2010-10-21 13:36:27)

I guess you changed permission to allow read via windows share.

Next time backup using TAR. That way permissions are kept within tar archive nomatter permissions on the archive itself.

Fonz has a shared funplug tar package.

yes,

but surly there is some reason to why bound4h felt the urge to chmod and chown.

I think that bound4h was troubleshooting some sort of permissions problem and received some (bad) advice from someone to chmod and chown every file on the hard disk, without fully understanding the ramifications.  Going forward, bound4h may have thought that chmod and chowning his ffp backup was a good idea for some reason; probably thinking that it would make the backup easier to manage somehow.

The deal is, once you've installed a fun_plug of some sort on the hard disk, you've really got two classes of the data on the disk.  One is the data stored via the samba shares, and the other is any files that are part of a fun_plug installation, like /mnt/HD_a2/ffp.

(Yeah, technically, the ffp files can be in a samba share, depending on how the shares are configured, but try to distinguish ffp files from movie or audio files, for example)

As far as I know, files that are placed on (copied to) the NAS via the samba shares have perm bits of 777 and are owned by root.  Samba provides the share-level access permissions to attached clients according to the way shares are defined.

I think that bound4h's problem was that s/he was having some sort of permission problem manipulating the files via the samba share.  One thing to check when this happens is the permissions and ownership.  Fixing them to be 777 and root can often restore the ability to manipulate the files again via samba.

It isn't clear how the files in the samba share got the wrong permissions, if indeed that is what happened.  In my experience it can be caused by someone placing files on the disk in some other way than via a samba share, like by using wget or transmission to grab files.  If you want these downloaded files to be accessible on the samba share as audio or video files, then you might have to change them to 777 root.

As pointed out in this thread, perms and ownership do matter for "fun_plug related" files.  There is no reason to jiggle the perms/owner on files when backing them up with cp, tar, rsync or whatever.

Yes, if you were just making the backup so that you could refer back to it for settings, etc, that would be ok.  If you ever wanted to restore a working ffp from that backup, you would have problems though.

As a rule, I rarely manipulate "system" files via the shares (Finder in your case) because of these issues you see.  I ssh in for that type of work.

Here's what would have worked well for you in this case:

login with ssh or telnet

copy the ffp folder from vol1 to vol2 using cp -a, like you did.

cd to the directory containing the ffp directory on vol 2 (or vol 1), not the ffp dir itself

create a tar file archive of the ffp directory like someone suggested:

tar cvf ffp.tar ffp

This will create a ffp.tar file.  Then you can chmod/chown that tar file however you want, perhaps to 777 root.  At that point, the tar file will appear on your vol2 share and then you can use Finder to copy it from that vol2 share to that third share you were talking about.

The single tar file is nice because it is a single file that is easily copied and stored on that third volume and all the file attributes are maintained.