File permission issues

[toothandnail]

I've just got my HDA up and running again after a couple of months (I moved, changed ISPs and ended up with a lousy router which would have required building a new HDA, for which I didn't have time....).

Everything seems to be working as it should - I can get the dashboard up and start install apps. But, I cannot copy files to any of the existing shares. I've looked at the trouble shooting section, and everything looks correct - the shares are writeable, and I'm mounting them as a user on the HDA. At present, I'm mounting from the command line (I will probably add some /etc/fstab entries, but don't want to do that until I get the problem sorted out). Mount command I've used is as below:

Code: Select all

mount -t cifs //hda/music Music -o user=notme2%xxxx

If I then execute the mount command without arguments, this is what I get for the share I've just mounted:

Code: Select all

//hda/music on /home/notme2/Music type cifs (rw,mand)

After a bit of hunting, I find that the 'mand' indicates that mandatory access controls are in force. No idea where that comes from... Anyway, with shares mounted that way, I can read and access files in the share. However, I cannot perform any operation which involves writing to files. I cannot delete any file already in the share area, nor can I copy files into the share area - I get permission denied every time.

I've ssh'd into the HDA, as the same user and I can read and write to the share area that way. Using a fish link from Midnight Commander, I've been able to copy files to the same share area that gives me permission denied errors when it is mounted.

Looking in /var/log/samba on the HDA, there is a log for the machine I'm logging in from, but it is zero length and has not been updated since last night sometime. Looking at the only log that is being updated today (nmbd.log), it has multiple error entries as below:

Code: Select all

[2010/07/30 12:35:33, 0] nmbd/nmbd_browsesync.c:350(find_domain_master_name_query_fail) find_domain_master_name_query_fail: Unable to find the Domain Master Browser name IBMPEERS<1b> for the workgroup IBMPEERS. Unable to sync browse lists in this workgroup.

I'm at a loss at the moment. Can anyone tell me what I've not got set up correctly? I'm also a bit puzzled by the 'IBMPEERS<1b>' entry in the log. Don't know where the <1b> has come from - its almost as though there is a character incorrectly appended to the workgroup name in the config?

Can anyone give me examples of what sort of mount command they would use to mount HDA shares from a Linux box? Or does anyone have any ideas what else I can do to find the cause of the problem?

Paul.

[toothandnail]

Further to this problem, it seems to be linked to different versions of Linux. I have been able to write to files in shares from Vectorlinux 6.0, using the following in /etc/fstab:

Code: Select all

//hda/movies /home/tooth/smb cifs noauto,users,rw,user=tooth,password=xxxx 0 0

Root access is needed to mount the share, but I am then able to write to it as a normal user. However, the same mount command under Salix64 fails to allow the user to write or delete files - a normal user can view and copy files from the share, but nothing involving write access. Root is able to write files, but that is really not much use in this context.

I wondered if it might be differences in the versions of Samba in use, but that doesn't seem to be the problem - both Vector and Salix are using Samba 3.4.3.

Any ideas where to look to solve the problem? Most of my machines are Linux based, so eventually I would rather go to NFS for shares, but for the moment, being able to write to shares is pretty much a make or break proposition for Amahi in my use.

Paul.

[moredruid]

It might not be different versions of Samba but rather the CIFS and Fuse packages. You may want to look into that.

That said, you can use NFS next to Samba, they can coexist without issue (in fact I have this setup at home).

[toothandnail]

It might not be different versions of Samba but rather the CIFS and Fuse packages. You may want to look into that.

I guess that is a possibility. I've got several distros on the laptop, so I got a chance to play with several. With Fedora 12, I can use gigalo to mount a share on the hda and access it read/write without problems. Strangely enough, late yesterday, I tried the same thing from Salix64. And this time, not only did gigalo connect, it allowed me to copy files as a normal user. Very strange. It didn't allow me to unmount the share, which was also strange. I'll have to have more of a look at that.

That said, you can use NFS next to Samba, they can coexist without issue (in fact I have this setup at home).

Are you sharing the same areas with both NFS and Samba? I tired that with my Icy Box NAS and got some very strange effects. For some reason, the Icy Box was setting different owner/group and permissions on files transfered via NFS to those transfered via Samba. Mind you, the Icy Box does do some very strange things at the best of times - it was one of the main reasons I started looking at something like Amahi.

I'll have to set up exports and hosts.allow, hosts.deny and try NFS in the next couple of days. Should be a better option for a largely Linux based network.

Paul.

[moredruid]

yup, using the same "shares" (i.e. the samba share "movies" & the NFS export /var/hda/files/movies).
never looked at ownership & permissions since I've never had issues
Note however that you can set some permission settings in NFS (I think default is 640) and that the Icybox is doing that.