support asked me to attach log files but still over 31mb even after deleting shares
I found that the main bulk of the log file was copies of thumnails. So I deleted them, as they were totally irrelvant to the operation of the device.
But, since I wasn’t entirely happy that I knew what I was sending to WD from my system, I didn’t bother in the end, not that it was looking hopeful that I’d get a solution if I did.
But I know that there is an FTP server that can be used to upload large log files.
It does seem a bit silly that the device generates a log file, including stuff that has no diagnostic value, that is larger than can be emailed to support…
Support is just playing the delay-game by throwing us crumbs now and then. They have no clue how to fix the issue it seems. Its’ been 7 days now.
Unfortunately, if there is no work around for an issue like this, support won’t be able to do much until a fix is released. Just know that we are working on the fix and haven’t forgotten any of you.
Support is just playing the delay-game by throwing us crumbs now and then. They have no clue how to fix the issue it seems. Its’ been 7 days now.
Unfortunately, if there is no work around for an issue like this, support won’t be able to do much until a fix is released. Just know that we are working on the fix and haven’t forgotten any of you.
I found that new ‘Shared Media’ folders created by Twonky had permissions such that I couldn’t access them using Windows File Explorer on mapped shares. Whereas the old shares were accessible.
Ussing SSH to access the linux command line, I used ls -la to check the owner, group and permissions for these folders, and spotted that the new folders were different.
Working folders had properties:
drwxrwxr-x root shares
whereas the new folders had properties:
drwxrwxrw- root root
On the thread above, Kazzzzz (WD Staff) suggested the following command to fix the group ownership:
This will find all shares that have group ownership as ‘root’, and set them to group ownership ‘shares’.
Now, I’m NOT saying that this is the solution to the problem people are having with inability to access their shares, but it might be worth using SSH/Linux to have a look at the folder permissions of ‘working’ folders and ‘broken’ folders, and see if there are obvious differences.
I’m not sure what the folder properties should be…
You can also use chmod -R 777 to set the folders under Public to read/write/execute. That fixed my device.
I wrote instructions on Tuesday , a few pages down, in this thread.
Of course, people should use SSH at their own risk.
I also turned off the automatic updates for my device. I want no more surprises caused by poorly-tested buggy firmware. I will take the updated firmware once I know there are no big issues.
im not confident eneogh to do that myself using ssh . hoping for a fix from WD
jsstx wrote:
Hi cpt_paranoia.
You can also use chmod -R 777 to set the folders under Public to read/write/execute. That fixed my device.
I wrote instructions on Tuesday , a few pages down, in this thread.
Of course, people should use SSH at their own risk.
I also turned off the automatic updates for my device. I want no more surprises caused by poorly-tested buggy firmware. I will take the updated firmware once I know there are no big issues.
For those of you still experiencing folder permission issues, we now have a patch available that should fix the issue. However, you will need to call into Support for them to install the patch for you. Please call in using the phone number for your region.
Below is the contact information for WD’s Support.
You can also use chmod -R 777 to set the folders under Public to read/write/execute. That fixed my device.
Yes, that’s what I did, too; I reported it on the thread I linked. But I’m not convinced it’s the ‘right’ solution, since the ‘working’ folders didn’t have 777 permissions. I’d rather get it right than use a 777 unix kludge.
I think it’s certainly worth people investigating the owner/group/permissions on the folders.
im not confident eneogh to do that myself using ssh . hoping for a fix from WD
Understood. And you really shouldn’t be expected to, as a consumer user: I’m making the suggestion to the more technically-skilled users for diagnostic purposes.
im not confident eneogh to do that myself using ssh . hoping for a fix from WD
Understandable that one doesn’t want to use the command line to make changes. The end user shouldn’t have too. There may be a slightly easier way (if the WD fix mentioned previously doesn’t work) to modify the permissions without using the command line. Use an FTP program like the free FileZilla program to connect through SSH. From there you can navigate to the public folder (/DataVolume/shares/Public) and select the folder (or folders) and change their permissions from a graphical user interface.
For those of you still experiencing folder permission issues, we now have a patch available that should fix the issue. However, you will need to call into Support for them to install the patch for you. Please call in using the phone number for your region.
Below is the contact information for WD’s Support.
I think this find command will fix the current folders. But any new folders will again be created with the wrong group. The fix needs to be fixing the default group. I tested on my system and created a folder in the Public folder. It had the correct group. I am testing on firmware version 308 using windows explorer. I then created a folder in the Public/Shared Music folder it aalso had the correct group.
I’m wondering how other people are creating the new folders. It appears that samba defaults to group share.
How are the people that have the problem creating these new folders?
