Hi everyone, is it possible to share files and even folders across sharepoint document libraries? Thank you for your replies.

Greetings, The short answer is no. SharePoint does not have native functionality for files/folders from library A to co-exist as the same file/folder (if this is what you mean by 'share') within library B. Copies of your files/folders could exist in multiple libraries, however for management purposes, I would caution against this type of solution. With this said, if you can elaborate on your desired scenario, perhaps we can offer a plausible solution. For example, you can certainly create roll-up views which present the contents from multiple libraries for end user consumption in a central location if this is acceptable. Let us know your scenario, perhaps we can help. Kind regards, CraigSenior Systems Engineer / SharePoint Architect | MSDN Profile | Blog | Twitter Microsoft Community Contributor Award 2011 Recipient

You can upload a document to Library A and then link to it in Library B using the Link to a Document content type: http://techtrainingnotes.blogspot.com/2007/08/sharepoint-adding-hyperlinks-to-doc.html (an old 2007 article that still applies) You can use SharePoint Designer to create a Data Source that points to Library A, then add a Data View Web Part to site B that uses that Data Source. Using a trick or two you can export a library web part from Site A and import it into Site B. http://techtrainingnotes.blogspot.com/2009/03/sharepoint-one-library-multiple-sites.html (an old 2007/2010 article that should still work in 2013) Mike Smith TechTrainingNotes.blogspot.com my SP customization book

Mike, thanks for bringing up the 'Link to a Document' content type. I was thinking about this request in terms of a synchronized copy of the original SPFile (i.e. the original document), its content type and columns/values. The 'Link to a Document' content type essentially creates an .aspx redirect web page and has a Hyperlink column that stores the URL and link title to the original document. In this context, your original document in library A is a completely separate file from the 'link' that is created in library B. I've been down this road before and a 'Link to a Document' could work depending on the business requirements. Some thoughts on this approach: You'll have to manually create the links in library B. There is no out of the box automatic mechanism that would 'sync' documents in library A by automatically creating links in library B.The file permissions on the original document in library A are separate from the 'link' in library B. Remember that the link is a new .aspx redirect file pointing to the original document in library A.If the two document libraries share the same permissions inheritance, you should be fine in terms of users that can access the document in library A can access the link in library B.If the permissions inheritance is different, than you'll have to manually make them the same or set the way you want them to be.One nice thing about the 'Link to a Document' content type is that if the original document name changes (i.e. the file name changes) the link in library B will be updated without intervention.Another nice thing is that the icon in library B is the same icon for the document you'd see in library A, but with a link overlay. This is good so at a glance you'll know what type of document the link points to without having to click on the link.There is no 'Link to Folder'. Using this approach, you'd have to manually create the folders.Any columns on document A (i.e. custom columns on the original document and its content type) are not automatically included in the link document in library B. You would have to create a new content type inheriting from 'Link to a Document' and add the columns to it then manually add the custom column values.You could write a PowerShell Script to 'sync' documents in library A with links in library B. Such a script could also 'sync' the folders and could also be written to modify the link (.aspx redirect file) permissions in case the two libraries have different permissions to ensure users see only what they are supposed to see. The PowerShell Script could then be configured as a scheduled task (scheduled execution). This could also be done in a custom timer job (scheduled execution), and as an event receiver (instant execution).Opening up a whole new can of worms, the PowerShell Script (or custom timer job/event receiver) mentioned above could be written to 'sync' the columns and values from the original document content type and copied into the link (provided that you created a new content type inheriting from the 'Link to a Document' that contains all custom columns found in the original document from library A)I would be sure to explicitly remove items of content type 'Link to a Document' from search scopes to ensure that they are not displayed in search results. A Data View Web Part, or exporting a library web part (I like that trick and use it myself :) could be used and documents from library A would be automatically reflected in said web part - one of these two could be the easiest solution. A content query web part could also be used. A custom developed web part may be the answer... The satisfactory or best solution really depends on the underlying business requirements. Are library A and B in the same or different site collections? Do the same group or a different group of people need to access library A and library B? Do the documents have custom columns and if so are they required in both library A and library B? What is the use case for needing document 'sharing' across libraries in the first place? I've been down these roads many times in many different scenarios - and now that I've written a wall of text, I hope my thoughts/insight helps and I'll wait for the op provide clarity into the scenario at hand before I add additional thoughts. Cheers, Craig Senior Systems Engineer / SharePoint Architect | MSDN Profile | Blog | Twitter Microsoft Community Contributor Award 2011 Recipient

thank you all for your tips I am going to check all the possibilities.